From: Al Viro <viro@ZenIV.linux.org.uk>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [git pull] vfs.git part 2
Date: Fri, 12 Jul 2013 16:48:34 +0100 [thread overview]
Message-ID: <20130712154833.GA4165@ZenIV.linux.org.uk> (raw)
In-Reply-To: <8738rk9eai.fsf@rasmusvillemoes.dk>
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 ;-/ 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...
next prev parent reply other threads:[~2013-07-12 15:48 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 [this message]
2013-07-12 16:30 ` Rasmus Villemoes
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
-- strict thread matches above, loose matches on Subject: below --
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=20130712154833.GA4165@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
/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.