On 9 March 2015 at 16:16, David Drysdale <drysdale@xxxxxxxxxx> wrote: > On Mon, Mar 9, 2015 at 2:32 PM, Michael Kerrisk (man-pages) > <mtk.manpages@xxxxxxxxx> wrote: >> On 03/09/2015 03:00 PM, David Drysdale wrote: >>> Signed-off-by: David Drysdale <drysdale@xxxxxxxxxx> >> >> Hi David, >> >> The text looks good insofar as it goes. But, it would be helpful >> to have sentence or to that explains why this flag exists. >> Could you add that, please? >> >> Thanks, >> >> Michael > > How about something like: > > This feature allows applications to be sure that the opened file > is within the specified directory, regardless of the original > source of the pathname argument. Some security-conscious pro‐ > grams may further ensure this by imposing a system call filter > (with seccomp(2)) that requires this flag for all open() opera‐ > tions, so that the program cannot open files outside of speci‐ > fied directories even if subverted. > > (Also, I realize that I somehow failed to notice that the flags > are listed in alphabetical order, so I'll move the text up, as > in the updated diff below). That looks good to me. Thanks! Cheers, Michael > --- > man2/open.2 | 44 ++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 44 insertions(+) > > diff --git a/man2/open.2 b/man2/open.2 > index 956531b24b26..ece1fa90775a 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. > @@ -984,6 +1021,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 > -- > 2.2.0.rc0.207.ga3a616c -- 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 fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
