All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: linux-kernel@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [git pull] vfs.git part 2
Date: Fri, 12 Jul 2013 16:30:45 +0000	[thread overview]
Message-ID: <87wqovviyy.fsf@rasmusvillemoes.dk> (raw)
In-Reply-To: 20130712154833.GA4165@ZenIV.linux.org.uk

Al Viro <viro@ZenIV.linux.org.uk> writes:

> On Fri, Jul 12, 2013 at 12:02:45PM +0000, Rasmus Villemoes wrote:
>
>> But isn't the problem the case where dirname does not exist? I.e., the
>> application has to make sure that "/some/where" exists and is a directory
>> before open("/some/where", O_CREAT | O_TMPFILE | O_RDWR, 0666) can be
>> relied upon to fail on kernels not recognizing O_TMPFILE, instead of
>> just creating "where" in "/some".
>> 
>> Just thinking out loud, and please tell me to shut up if it doesn't make
>> sense: The documentation for O_DIRECTORY seems to imply that one could
>> require O_DIRECTORY to be given when using O_TMPFILE. The "If pathname
>> is not a directory, cause the open to fail" certainly seems to make
>> sense when O_TMPFILE is used, and older kernels should complain when
>> seeing the O_CREAT|O_DIRECTORY combination. It is a hack, though.
>
> They should, but they won't ;-/

I see; I should test before I post, but...

> It's the same problem - we do *not* validate the flags argument.
> We'll get to do_last(), hit lookup_open(), which will create the
> sucker and go to finish_open_created.  Which is past the logics
> checking for LOOKUP_DIRECTORY trying to return a non-directory and it
> would've been too late to fail anyway - the file has already been
> created.  IOW, O_DIRECTORY is ignored when O_CREAT is present *and*
> file didn't exist already.  In that case we almost certainly can treat
> that as a bug (i.e. start failing open() on O_CREAT | O_DIRECTORY in
> all cases - I'd be _very_ surprised if somebody called open() with
> such combination of flags), but that doesn't help with older
> kernels...

... it seems that if one then omits O_CREAT, things work out ok, as long
as one uses O_RDWR (which is the only sane thing to do with O_TMPFILE, I
guess):

open("/tmp/test/dir", O_DIRECTORY | O_RDWR, 0666) -> -1; Is a directory
open("/tmp/test/dir", O_DIRECTORY | O_RDONLY, 0666) -> 3; Success
open("/tmp/test/file", O_DIRECTORY | O_RDWR, 0666) -> -1; Not a directory
open("/tmp/test/link_to_file", O_DIRECTORY | O_RDWR, 0666) -> -1; Not a directory
open("/tmp/test/link_to_nowhere", O_DIRECTORY | O_RDWR, 0666) -> -1; No such file or directory
open("/tmp/test/link_to_dir", O_DIRECTORY | O_RDWR, 0666) -> -1; Is a directory
open("/tmp/test/link_to_dir", O_DIRECTORY | O_RDONLY, 0666) -> 3; Success
open("/tmp/test/link_to_dir", O_NOFOLLOW | O_DIRECTORY | O_RDWR, 0666) -> -1; Too many levels of symbolic links
open("/tmp/test/link_to_dir", O_NOFOLLOW | O_DIRECTORY | O_RDONLY, 0666) -> -1; Too many levels of symbolic links

(The above flags are what an old kernel would effectively see with or
without O_TMPFILE present, I suppose.)

How about simply making O_TMPFILE == O_DIRECTORY | O_RDWR |
O_TMPFILE_INTERNAL, and letting the correct use be 

open("/some/dir", O_TMPFILE) [with or without a mode argument]

Using O_DIRECTORY when we don't want to open a directory, and omitting
O_CREAT when we do want to create something new, is somewhat
counter-intuitive, but I think this would solve the problem with old
kernels.

Rasmus


  reply	other threads:[~2013-07-12 16:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-03 12:29 [git pull] vfs.git part 2 Al Viro
2013-07-11 21:42 ` Linus Torvalds
2013-07-12  5:48   ` Al Viro
2013-07-12 11:54     ` Al Viro
2013-07-12 12:02     ` Rasmus Villemoes
2013-07-12 15:48       ` Al Viro
2013-07-12 16:30         ` Rasmus Villemoes [this message]
2013-07-12 19:13           ` Al Viro
2013-07-12 19:39             ` Al Viro
2013-07-12 20:21               ` Linus Torvalds
2013-07-12 21:16                 ` Al Viro
2013-07-15 23:13                 ` Rasmus Villemoes
2013-07-12 19:42             ` Linus Torvalds
2013-07-12 20:02               ` Al Viro
2017-07-05  7:14 Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wqovviyy.fsf@rasmusvillemoes.dk \
    --to=linux@rasmusvillemoes.dk \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.