From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f171.google.com ([209.85.217.171]:32949 "EHLO mail-lb0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932178AbbCIPzK convert rfc822-to-8bit (ORCPT ); Mon, 9 Mar 2015 11:55:10 -0400 MIME-Version: 1.0 Reply-To: mtk.manpages@gmail.com In-Reply-To: References: <1425909612-28034-1-git-send-email-drysdale@google.com> <1425909612-28034-4-git-send-email-drysdale@google.com> <54FDAF16.2030407@gmail.com> From: "Michael Kerrisk (man-pages)" Date: Mon, 9 Mar 2015 16:54:47 +0100 Message-ID: Subject: Re: [PATCHv3 man-pages 3/3] open.2: describe O_BENEATH flag Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: fstests-owner@vger.kernel.org To: David Drysdale Cc: "linux-kernel@vger.kernel.org" , Alexander Viro , Kees Cook , "Eric W. Biederman" , Greg Kroah-Hartman , Meredydd Luff , Will Drewry , Jorge Lucangeli Obes , Ricky Zhou , Lee Campbell , Julien Tinnes , Mike Depinet , James Morris , Andy Lutomirski , Paolo Bonzini , Paul Moore , Christoph Hellwig , Linux API , LSM List , fstests List-ID: On 9 March 2015 at 16:16, David Drysdale wrote: > On Mon, Mar 9, 2015 at 2:32 PM, Michael Kerrisk (man-pages) > wrote: >> On 03/09/2015 03:00 PM, David Drysdale wrote: >>> Signed-off-by: David Drysdale >> >> 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/