| Message ID | 1439458366-8223-4-git-send-email-drysdale@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Aug 13, 2015 at 2:32 AM, David Drysdale <drysdale@google.com> wrote:
> Signed-off-by: David Drysdale <drysdale@google.com>
What's the behavior wrt fcntl(F_GETFL, etc)?
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 13 August 2015 at 19:38, Andy Lutomirski <luto@amacapital.net> wrote: > On Thu, Aug 13, 2015 at 2:32 AM, David Drysdale <drysdale@google.com> wrote: >> Signed-off-by: David Drysdale <drysdale@google.com> > > What's the behavior wrt fcntl(F_GETFL, etc)? I would presume that O_BENEATH is one of the so-called "file creation flags". See this paragraph of the DESCRIPTION: In addition, zero or more file creation flags and file status flags can be bitwise-or'd in flags. The file creation flags are O_CLOEXEC, O_CREAT, O_DIRECTORY, O_EXCL, O_NOCTTY, O_NOFOLLOW, O_TMPFILE, O_TRUNC, and O_TTY_INIT. The file status flags are all of the remaining flags listed below. The distinction between these two groups of flags is that the file status flags can be retrieved and (in some cases) modified; see fcntl(2) for details. David, presuming this is correct (I can't see how O_BENEATH could be a "file *status* flag"), your patch should also add O_BENEATH to the list in that paragraph. Cheers, Michael
On Fri, Aug 14, 2015 at 6:33 AM, Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> wrote: > On 13 August 2015 at 19:38, Andy Lutomirski <luto@amacapital.net> wrote: >> On Thu, Aug 13, 2015 at 2:32 AM, David Drysdale <drysdale@google.com> wrote: >>> Signed-off-by: David Drysdale <drysdale@google.com> >> >> What's the behavior wrt fcntl(F_GETFL, etc)? > > I would presume that O_BENEATH is one of the so-called "file creation > flags". See this paragraph of the DESCRIPTION: > > In addition, zero or more file creation flags and file status > flags can be bitwise-or'd in flags. The file creation flags are > O_CLOEXEC, O_CREAT, O_DIRECTORY, O_EXCL, O_NOCTTY, O_NOFOLLOW, > O_TMPFILE, O_TRUNC, and O_TTY_INIT. The file status flags are > all of the remaining flags listed below. The distinction between > these two groups of flags is that the file status flags can be > retrieved and (in some cases) modified; see fcntl(2) for details. > > David, presuming this is correct (I can't see how O_BENEATH could be a > "file *status* flag"), your patch should also add O_BENEATH to the > list in that paragraph. Yeah, O_BENEATH makes sense as a file creation flag; I'll add it to that list -- thanks for spotting. > Cheers, > > Michael > > > > -- > Michael Kerrisk > Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ > Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 14, 2015 at 2:29 AM, David Drysdale <drysdale@google.com> wrote: > On Fri, Aug 14, 2015 at 6:33 AM, Michael Kerrisk (man-pages) > <mtk.manpages@gmail.com> wrote: >> On 13 August 2015 at 19:38, Andy Lutomirski <luto@amacapital.net> wrote: >>> On Thu, Aug 13, 2015 at 2:32 AM, David Drysdale <drysdale@google.com> wrote: >>>> Signed-off-by: David Drysdale <drysdale@google.com> >>> >>> What's the behavior wrt fcntl(F_GETFL, etc)? >> >> I would presume that O_BENEATH is one of the so-called "file creation >> flags". See this paragraph of the DESCRIPTION: >> >> In addition, zero or more file creation flags and file status >> flags can be bitwise-or'd in flags. The file creation flags are >> O_CLOEXEC, O_CREAT, O_DIRECTORY, O_EXCL, O_NOCTTY, O_NOFOLLOW, >> O_TMPFILE, O_TRUNC, and O_TTY_INIT. The file status flags are >> all of the remaining flags listed below. The distinction between >> these two groups of flags is that the file status flags can be >> retrieved and (in some cases) modified; see fcntl(2) for details. >> >> David, presuming this is correct (I can't see how O_BENEATH could be a >> "file *status* flag"), your patch should also add O_BENEATH to the >> list in that paragraph. > > Yeah, O_BENEATH makes sense as a file creation flag; I'll add it > to that list -- thanks for spotting. Should there be a test that you can't clear O_BENEATH with F_SETFL? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 14, 2015 at 3:17 PM, Andy Lutomirski <luto@amacapital.net> wrote: > On Fri, Aug 14, 2015 at 2:29 AM, David Drysdale <drysdale@google.com> wrote: >> On Fri, Aug 14, 2015 at 6:33 AM, Michael Kerrisk (man-pages) >> <mtk.manpages@gmail.com> wrote: >>> On 13 August 2015 at 19:38, Andy Lutomirski <luto@amacapital.net> wrote: >>>> On Thu, Aug 13, 2015 at 2:32 AM, David Drysdale <drysdale@google.com> wrote: >>>>> Signed-off-by: David Drysdale <drysdale@google.com> >>>> >>>> What's the behavior wrt fcntl(F_GETFL, etc)? >>> >>> I would presume that O_BENEATH is one of the so-called "file creation >>> flags". See this paragraph of the DESCRIPTION: >>> >>> In addition, zero or more file creation flags and file status >>> flags can be bitwise-or'd in flags. The file creation flags are >>> O_CLOEXEC, O_CREAT, O_DIRECTORY, O_EXCL, O_NOCTTY, O_NOFOLLOW, >>> O_TMPFILE, O_TRUNC, and O_TTY_INIT. The file status flags are >>> all of the remaining flags listed below. The distinction between >>> these two groups of flags is that the file status flags can be >>> retrieved and (in some cases) modified; see fcntl(2) for details. >>> >>> David, presuming this is correct (I can't see how O_BENEATH could be a >>> "file *status* flag"), your patch should also add O_BENEATH to the >>> list in that paragraph. >> >> Yeah, O_BENEATH makes sense as a file creation flag; I'll add it >> to that list -- thanks for spotting. > > Should there be a test that you can't clear O_BENEATH with F_SETFL? > > --Andy I'll add a test that fcntl(F_SETFL) silently ignores the file creation flags, including O_BENEATH. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/man2/open.2 b/man2/open.2 index f49ab3042161..d09511f9ffb0 100644 --- a/man2/open.2 +++ b/man2/open.2 @@ -201,6 +201,43 @@ See for further details. See also BUGS, below. .TP +.B O_BENEATH " (since Linux 4.??)" +Ensure that the +.I pathname +is beneath the current working directory (for +.BR open (2)) +or the +.I dirfd +(for +.BR openat (2)). +If the +.I pathname +is absolute or contains a path component of "..", the +.BR open () +fails with the error +.BR EPERM. +This occurs even if ".." path component would not actually +escape the original directory; for example, a +.I pathname +of "subdir/../filename" would be rejected. +Path components that are symbolic links to absolute paths, or that are +relative paths containing a ".." component, will also cause the +.BR open () +operation to fail with the error +.BR EPERM. + +This feature allows applications to be sure that the opened file is +within the specified directory, regardless of the original source of the +.I pathname +argument. +Some security-conscious programs may further ensure +this by imposing a system call filter (with +.BR seccomp (2)) +that requires this flag for all +.BR open () +operations, so that the program cannot open files outside of +specified directories even if subverted. +.TP .BR O_CLOEXEC " (since Linux 2.6.23)" .\" NOTE! several other man pages refer to this text Enable the close-on-exec flag for the new file descriptor. @@ -1015,6 +1052,13 @@ did not match the owner of the file and the caller was not privileged The operation was prevented by a file seal; see .BR fcntl (2). .TP +.B EPERM +The +.B O_BENEATH +flag was specified and the +.I pathname +was not beneath the relevant directory. +.TP .B EROFS .I pathname refers to a file on a read-only filesystem and write access was
Signed-off-by: David Drysdale <drysdale@google.com> --- man2/open.2 | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) -- 2.5.0.rc2.392.g76e840b -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html