Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Tue, Jul 08, 2014 at 05:54:24PM +0100, David Drysdale wrote: > > How is this implemented in FreeBSD? I can't find any references to > > O_BENEATH_ONLY except for your patchset. > > FreeBSD have the relative-only behaviour for openat() relative to a > Capsicum capability dfd [1], and for a process in capability-mode [2], > but they don't have the O_BENEATH_ONLY as a separately-accessible > openat() flag. However, it seemed like a more widely useful idea so > separating it out was suggested. In that case we should make sure to use the same name and semantics for it. As far as I'm concerned I'd prefer a less clumsy name like O_BENEATH. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Tue, Jul 08, 2014 at 05:54:24PM +0100, David Drysdale wrote: How is this implemented in FreeBSD? I can't find any references to O_BENEATH_ONLY except for your patchset. FreeBSD have the relative-only behaviour for openat() relative to a Capsicum capability dfd [1], and for a process in capability-mode [2], but they don't have the O_BENEATH_ONLY as a separately-accessible openat() flag. However, it seemed like a more widely useful idea so separating it out was suggested. In that case we should make sure to use the same name and semantics for it. As far as I'm concerned I'd prefer a less clumsy name like O_BENEATH. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Tue, Jul 8, 2014 at 1:03 PM, Christoph Hellwig wrote: > On Mon, Jun 30, 2014 at 11:28:01AM +0100, David Drysdale wrote: >> Add a new O_BENEATH_ONLY flag for openat(2) which restricts the >> provided path, rejecting (with -EACCES) paths that are not beneath >> the provided dfd. In particular, reject: >> - paths that contain .. components >> - paths that begin with / >> - symlinks that have paths as above. > > > How is this implemented in FreeBSD? I can't find any references to > O_BENEATH_ONLY except for your patchset. FreeBSD have the relative-only behaviour for openat() relative to a Capsicum capability dfd [1], and for a process in capability-mode [2], but they don't have the O_BENEATH_ONLY as a separately-accessible openat() flag. However, it seemed like a more widely useful idea so separating it out was suggested. [1] http://fxr.watson.org/fxr/source/kern/vfs_lookup.c?v=FREEBSD10#L238 [2] http://fxr.watson.org/fxr/source/kern/vfs_lookup.c?v=FREEBSD10#L171 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Tue, Jul 08, 2014 at 02:04:45PM +0100, Meredydd Luff wrote: > On 8 July 2014 13:51, Christoph Hellwig wrote: > > Yeah, it won't work for an explicit directory - I was thinking of > > working relative to $CWD. > > I think that would sacrifice far too much flexibility. Even without > Capsicum, it would be worthwhile to be able to wire up a static > seccomp-bpf filter to enforce constraints such as "you can open files > under fd#5 for reading, but you can only write to files under fd#6, > and you can't do any global lookups." Yeah, I didn't intend to advocate this further after your reply. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On 8 July 2014 13:51, Christoph Hellwig wrote: > Yeah, it won't work for an explicit directory - I was thinking of > working relative to $CWD. I think that would sacrifice far too much flexibility. Even without Capsicum, it would be worthwhile to be able to wire up a static seccomp-bpf filter to enforce constraints such as "you can open files under fd#5 for reading, but you can only write to files under fd#6, and you can't do any global lookups." Meredydd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Tue, Jul 08, 2014 at 01:48:27PM +0100, Meredydd Luff wrote: > How would that work? The directory beneath which openat is looking is > conveyed in the dfd argument itself. If I'm understanding this right, > you'd have to pass a different value for "open relative to fd#5" and > "open relative to fd#5, but beneath it only", which doesn't sound > hugely elegant to me. Yeah, it won't work for an explicit directory - I was thinking of working relative to $CWD. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On 8 July 2014 13:07, Christoph Hellwig wrote: > There's two different AT_* namespaces. The flags that most *at syscalls > has, and the the one for the dfd argument, which currently only contains > AT_FDCWD, although a new constant has recently been proposed to it. > > Having an AT_BENEATH magic value for the dfd argument certainly feels > elegant to me How would that work? The directory beneath which openat is looking is conveyed in the dfd argument itself. If I'm understanding this right, you'd have to pass a different value for "open relative to fd#5" and "open relative to fd#5, but beneath it only", which doesn't sound hugely elegant to me. Meredydd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Mon, Jun 30, 2014 at 08:53:01AM -0700, Andy Lutomirski wrote: > > Wouldn't it need to be both O_BENEATH_ONLY (for openat()) and > > AT_BENEATH_ONLY (for other *at() functions), like O_NOFOLLOW and > > AT_SYMLINK_NOFOLLOW? (I.e. aren't the AT_* flags in a different > > numbering space than O_* flags?) > > > > Or am I misunderstanding? > > > > Ugh, you're probably right. I wish openat had separate flags and > atflags arguments. Oh well. There's two different AT_* namespaces. The flags that most *at syscalls has, and the the one for the dfd argument, which currently only contains AT_FDCWD, although a new constant has recently been proposed to it. Having an AT_BENEATH magic value for the dfd argument certainly feels elegant to me, but seems to be against the language for openat in Posix: "The openat() function shall be equivalent to the open() function except in the case where path specifies a relative path. In this case the file to be opened is determined relative to the directory associated with the file descriptor fd instead of the current working directory. If the file descriptor was opened without O_SEARCH, the function shall check whether directory searches are permitted using the current permissions of the directory underlying the file descriptor. If the file descriptor was opened with O_SEARCH, the function shall not perform the check. The oflag parameter and the optional fourth parameter correspond exactly to the parameters of open(). If openat() is passed the special value AT_FDCWD in the fd parameter, the current working directory shall be used and the behavior shall be identical to a call to open()." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Mon, Jun 30, 2014 at 11:28:01AM +0100, David Drysdale wrote: > Add a new O_BENEATH_ONLY flag for openat(2) which restricts the > provided path, rejecting (with -EACCES) paths that are not beneath > the provided dfd. In particular, reject: > - paths that contain .. components > - paths that begin with / > - symlinks that have paths as above. How is this implemented in FreeBSD? I can't find any references to O_BENEATH_ONLY except for your patchset. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Mon, Jun 30, 2014 at 11:28:01AM +0100, David Drysdale wrote: Add a new O_BENEATH_ONLY flag for openat(2) which restricts the provided path, rejecting (with -EACCES) paths that are not beneath the provided dfd. In particular, reject: - paths that contain .. components - paths that begin with / - symlinks that have paths as above. How is this implemented in FreeBSD? I can't find any references to O_BENEATH_ONLY except for your patchset. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Mon, Jun 30, 2014 at 08:53:01AM -0700, Andy Lutomirski wrote: Wouldn't it need to be both O_BENEATH_ONLY (for openat()) and AT_BENEATH_ONLY (for other *at() functions), like O_NOFOLLOW and AT_SYMLINK_NOFOLLOW? (I.e. aren't the AT_* flags in a different numbering space than O_* flags?) Or am I misunderstanding? Ugh, you're probably right. I wish openat had separate flags and atflags arguments. Oh well. There's two different AT_* namespaces. The flags that most *at syscalls has, and the the one for the dfd argument, which currently only contains AT_FDCWD, although a new constant has recently been proposed to it. Having an AT_BENEATH magic value for the dfd argument certainly feels elegant to me, but seems to be against the language for openat in Posix: The openat() function shall be equivalent to the open() function except in the case where path specifies a relative path. In this case the file to be opened is determined relative to the directory associated with the file descriptor fd instead of the current working directory. If the file descriptor was opened without O_SEARCH, the function shall check whether directory searches are permitted using the current permissions of the directory underlying the file descriptor. If the file descriptor was opened with O_SEARCH, the function shall not perform the check. The oflag parameter and the optional fourth parameter correspond exactly to the parameters of open(). If openat() is passed the special value AT_FDCWD in the fd parameter, the current working directory shall be used and the behavior shall be identical to a call to open(). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On 8 July 2014 13:07, Christoph Hellwig h...@infradead.org wrote: There's two different AT_* namespaces. The flags that most *at syscalls has, and the the one for the dfd argument, which currently only contains AT_FDCWD, although a new constant has recently been proposed to it. Having an AT_BENEATH magic value for the dfd argument certainly feels elegant to me How would that work? The directory beneath which openat is looking is conveyed in the dfd argument itself. If I'm understanding this right, you'd have to pass a different value for open relative to fd#5 and open relative to fd#5, but beneath it only, which doesn't sound hugely elegant to me. Meredydd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Tue, Jul 08, 2014 at 01:48:27PM +0100, Meredydd Luff wrote: How would that work? The directory beneath which openat is looking is conveyed in the dfd argument itself. If I'm understanding this right, you'd have to pass a different value for open relative to fd#5 and open relative to fd#5, but beneath it only, which doesn't sound hugely elegant to me. Yeah, it won't work for an explicit directory - I was thinking of working relative to $CWD. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On 8 July 2014 13:51, Christoph Hellwig h...@infradead.org wrote: Yeah, it won't work for an explicit directory - I was thinking of working relative to $CWD. I think that would sacrifice far too much flexibility. Even without Capsicum, it would be worthwhile to be able to wire up a static seccomp-bpf filter to enforce constraints such as you can open files under fd#5 for reading, but you can only write to files under fd#6, and you can't do any global lookups. Meredydd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Tue, Jul 08, 2014 at 02:04:45PM +0100, Meredydd Luff wrote: On 8 July 2014 13:51, Christoph Hellwig h...@infradead.org wrote: Yeah, it won't work for an explicit directory - I was thinking of working relative to $CWD. I think that would sacrifice far too much flexibility. Even without Capsicum, it would be worthwhile to be able to wire up a static seccomp-bpf filter to enforce constraints such as you can open files under fd#5 for reading, but you can only write to files under fd#6, and you can't do any global lookups. Yeah, I didn't intend to advocate this further after your reply. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Tue, Jul 8, 2014 at 1:03 PM, Christoph Hellwig h...@infradead.org wrote: On Mon, Jun 30, 2014 at 11:28:01AM +0100, David Drysdale wrote: Add a new O_BENEATH_ONLY flag for openat(2) which restricts the provided path, rejecting (with -EACCES) paths that are not beneath the provided dfd. In particular, reject: - paths that contain .. components - paths that begin with / - symlinks that have paths as above. How is this implemented in FreeBSD? I can't find any references to O_BENEATH_ONLY except for your patchset. FreeBSD have the relative-only behaviour for openat() relative to a Capsicum capability dfd [1], and for a process in capability-mode [2], but they don't have the O_BENEATH_ONLY as a separately-accessible openat() flag. However, it seemed like a more widely useful idea so separating it out was suggested. [1] http://fxr.watson.org/fxr/source/kern/vfs_lookup.c?v=FREEBSD10#L238 [2] http://fxr.watson.org/fxr/source/kern/vfs_lookup.c?v=FREEBSD10#L171 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Tue, Jul 1, 2014 at 1:53 PM, David Drysdale wrote: > On Mon, Jun 30, 2014 at 01:40:40PM -0700, Andi Kleen wrote: >> David Drysdale writes: >> >> > Add a new O_BENEATH_ONLY flag for openat(2) which restricts the >> > provided path, rejecting (with -EACCES) paths that are not beneath >> > the provided dfd. In particular, reject: >> > - paths that contain .. components >> > - paths that begin with / >> > - symlinks that have paths as above. >> >> How about bind mounts? >> >> -Andi >> >> -- >> a...@linux.intel.com -- Speaking for myself only > > Bind mounts won't get rejected because they just look like normal > path components. In other words, if dir/subdir is a bind mount to > /root/dir then: > fd = openat(AT_FDCWD, "dir/subdir", O_RDONLY|O_BENEATH_ONLY); > will work fine. Talking about David's efforts at porting Capsicum to Linux, I've already implemented support for Capsicum in OpenSSH. It shouldn't be complicated to enable it on Linux systems that support it. I would very like to see capsicum integrated into mainline, as it's a high quality sandbox solution, that will benefit a lot of server software that implement privilege separation. > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Mon, Jun 30, 2014 at 01:40:40PM -0700, Andi Kleen wrote: > David Drysdale writes: > > > Add a new O_BENEATH_ONLY flag for openat(2) which restricts the > > provided path, rejecting (with -EACCES) paths that are not beneath > > the provided dfd. In particular, reject: > > - paths that contain .. components > > - paths that begin with / > > - symlinks that have paths as above. > > How about bind mounts? > > -Andi > > -- > a...@linux.intel.com -- Speaking for myself only Bind mounts won't get rejected because they just look like normal path components. In other words, if dir/subdir is a bind mount to /root/dir then: fd = openat(AT_FDCWD, "dir/subdir", O_RDONLY|O_BENEATH_ONLY); will work fine. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Mon, Jun 30, 2014 at 01:40:40PM -0700, Andi Kleen wrote: David Drysdale drysd...@google.com writes: Add a new O_BENEATH_ONLY flag for openat(2) which restricts the provided path, rejecting (with -EACCES) paths that are not beneath the provided dfd. In particular, reject: - paths that contain .. components - paths that begin with / - symlinks that have paths as above. How about bind mounts? -Andi -- a...@linux.intel.com -- Speaking for myself only Bind mounts won't get rejected because they just look like normal path components. In other words, if dir/subdir is a bind mount to /root/dir then: fd = openat(AT_FDCWD, dir/subdir, O_RDONLY|O_BENEATH_ONLY); will work fine. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Tue, Jul 1, 2014 at 1:53 PM, David Drysdale drysd...@google.com wrote: On Mon, Jun 30, 2014 at 01:40:40PM -0700, Andi Kleen wrote: David Drysdale drysd...@google.com writes: Add a new O_BENEATH_ONLY flag for openat(2) which restricts the provided path, rejecting (with -EACCES) paths that are not beneath the provided dfd. In particular, reject: - paths that contain .. components - paths that begin with / - symlinks that have paths as above. How about bind mounts? -Andi -- a...@linux.intel.com -- Speaking for myself only Bind mounts won't get rejected because they just look like normal path components. In other words, if dir/subdir is a bind mount to /root/dir then: fd = openat(AT_FDCWD, dir/subdir, O_RDONLY|O_BENEATH_ONLY); will work fine. Talking about David's efforts at porting Capsicum to Linux, I've already implemented support for Capsicum in OpenSSH. It shouldn't be complicated to enable it on Linux systems that support it. I would very like to see capsicum integrated into mainline, as it's a high quality sandbox solution, that will benefit a lot of server software that implement privilege separation. -- To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Mon, Jun 30, 2014 at 1:40 PM, Andi Kleen wrote: > David Drysdale writes: > >> Add a new O_BENEATH_ONLY flag for openat(2) which restricts the >> provided path, rejecting (with -EACCES) paths that are not beneath >> the provided dfd. In particular, reject: >> - paths that contain .. components >> - paths that begin with / >> - symlinks that have paths as above. > > How about bind mounts? What's the problematic scenario? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
David Drysdale writes: > Add a new O_BENEATH_ONLY flag for openat(2) which restricts the > provided path, rejecting (with -EACCES) paths that are not beneath > the provided dfd. In particular, reject: > - paths that contain .. components > - paths that begin with / > - symlinks that have paths as above. How about bind mounts? -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Mon, Jun 30, 2014 at 8:49 AM, David Drysdale wrote: > On Mon, Jun 30, 2014 at 07:49:41AM -0700, Andy Lutomirski wrote: >> On Jun 30, 2014 3:36 AM, "David Drysdale" wrote: >> > >> > Add a new O_BENEATH_ONLY flag for openat(2) which restricts the >> > provided path, rejecting (with -EACCES) paths that are not beneath >> > the provided dfd. In particular, reject: >> > - paths that contain .. components >> > - paths that begin with / >> > - symlinks that have paths as above. >> >> I like this a lot. However, I think I'd like it even better if it >> were AT_BENEATH_ONLY so that it could be added to the rest of the *at >> family. >> >> --Andy > > Wouldn't it need to be both O_BENEATH_ONLY (for openat()) and > AT_BENEATH_ONLY (for other *at() functions), like O_NOFOLLOW and > AT_SYMLINK_NOFOLLOW? (I.e. aren't the AT_* flags in a different > numbering space than O_* flags?) > > Or am I misunderstanding? > Ugh, you're probably right. I wish openat had separate flags and atflags arguments. Oh well. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Mon, Jun 30, 2014 at 07:49:41AM -0700, Andy Lutomirski wrote: > On Jun 30, 2014 3:36 AM, "David Drysdale" wrote: > > > > Add a new O_BENEATH_ONLY flag for openat(2) which restricts the > > provided path, rejecting (with -EACCES) paths that are not beneath > > the provided dfd. In particular, reject: > > - paths that contain .. components > > - paths that begin with / > > - symlinks that have paths as above. > > I like this a lot. However, I think I'd like it even better if it > were AT_BENEATH_ONLY so that it could be added to the rest of the *at > family. > > --Andy Wouldn't it need to be both O_BENEATH_ONLY (for openat()) and AT_BENEATH_ONLY (for other *at() functions), like O_NOFOLLOW and AT_SYMLINK_NOFOLLOW? (I.e. aren't the AT_* flags in a different numbering space than O_* flags?) Or am I misunderstanding? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Jun 30, 2014 3:36 AM, "David Drysdale" wrote: > > Add a new O_BENEATH_ONLY flag for openat(2) which restricts the > provided path, rejecting (with -EACCES) paths that are not beneath > the provided dfd. In particular, reject: > - paths that contain .. components > - paths that begin with / > - symlinks that have paths as above. I like this a lot. However, I think I'd like it even better if it were AT_BENEATH_ONLY so that it could be added to the rest of the *at family. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
Add a new O_BENEATH_ONLY flag for openat(2) which restricts the
provided path, rejecting (with -EACCES) paths that are not beneath
the provided dfd. In particular, reject:
- paths that contain .. components
- paths that begin with /
- symlinks that have paths as above.
Signed-off-by: David Drysdale
---
arch/alpha/include/uapi/asm/fcntl.h | 1 +
arch/parisc/include/uapi/asm/fcntl.h | 1 +
arch/sparc/include/uapi/asm/fcntl.h | 1 +
fs/fcntl.c | 5 +++--
fs/namei.c | 43
fs/open.c| 4 +++-
include/linux/namei.h| 1 +
include/uapi/asm-generic/fcntl.h | 4
8 files changed, 43 insertions(+), 17 deletions(-)
diff --git a/arch/alpha/include/uapi/asm/fcntl.h
b/arch/alpha/include/uapi/asm/fcntl.h
index 09f49a6b87d1..b3e0b00ff9ed 100644
--- a/arch/alpha/include/uapi/asm/fcntl.h
+++ b/arch/alpha/include/uapi/asm/fcntl.h
@@ -33,6 +33,7 @@
#define O_PATH 04000
#define __O_TMPFILE01
+#define O_BENEATH_ONLY 02 /* no / or .. in openat path */
#define F_GETLK7
#define F_SETLK8
diff --git a/arch/parisc/include/uapi/asm/fcntl.h
b/arch/parisc/include/uapi/asm/fcntl.h
index 34a46cbc76ed..da4447775f87 100644
--- a/arch/parisc/include/uapi/asm/fcntl.h
+++ b/arch/parisc/include/uapi/asm/fcntl.h
@@ -21,6 +21,7 @@
#define O_PATH 02000
#define __O_TMPFILE04000
+#define O_BENEATH_ONLY 08000 /* no / or .. in openat path */
#define F_GETLK64 8
#define F_SETLK64 9
diff --git a/arch/sparc/include/uapi/asm/fcntl.h
b/arch/sparc/include/uapi/asm/fcntl.h
index 7e8ace5bf760..9f2635197cf0 100644
--- a/arch/sparc/include/uapi/asm/fcntl.h
+++ b/arch/sparc/include/uapi/asm/fcntl.h
@@ -36,6 +36,7 @@
#define O_PATH 0x100
#define __O_TMPFILE0x200
+#define O_BENEATH_ONLY 0x400 /* no / or .. in openat path */
#define F_GETOWN 5 /* for sockets. */
#define F_SETOWN 6 /* for sockets. */
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 72c82f69b01b..79f9b09fa46b 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -742,14 +742,15 @@ static int __init fcntl_init(void)
* Exceptions: O_NONBLOCK is a two bit define on parisc; O_NDELAY
* is defined as O_NONBLOCK on some platforms and not on others.
*/
- BUILD_BUG_ON(20 - 1 /* for O_RDONLY being 0 */ != HWEIGHT32(
+ BUILD_BUG_ON(21 - 1 /* for O_RDONLY being 0 */ != HWEIGHT32(
O_RDONLY| O_WRONLY | O_RDWR|
O_CREAT | O_EXCL| O_NOCTTY |
O_TRUNC | O_APPEND | /* O_NONBLOCK | */
__O_SYNC| O_DSYNC | FASYNC|
O_DIRECT| O_LARGEFILE | O_DIRECTORY |
O_NOFOLLOW | O_NOATIME | O_CLOEXEC |
- __FMODE_EXEC| O_PATH| __O_TMPFILE
+ __FMODE_EXEC| O_PATH| __O_TMPFILE |
+ O_BENEATH_ONLY
));
fasync_cache = kmem_cache_create("fasync_cache",
diff --git a/fs/namei.c b/fs/namei.c
index 80168273396b..e6b72531dfc7 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -646,7 +646,7 @@ static __always_inline void set_root(struct nameidata *nd)
get_fs_root(current->fs, >root);
}
-static int link_path_walk(const char *, struct nameidata *);
+static int link_path_walk(const char *, struct nameidata *, unsigned int);
static __always_inline void set_root_rcu(struct nameidata *nd)
{
@@ -819,7 +819,8 @@ static int may_linkat(struct path *link)
}
static __always_inline int
-follow_link(struct path *link, struct nameidata *nd, void **p)
+follow_link(struct path *link, struct nameidata *nd, unsigned int flags,
+ void **p)
{
struct dentry *dentry = link->dentry;
int error;
@@ -866,7 +867,7 @@ follow_link(struct path *link, struct nameidata *nd, void
**p)
nd->flags |= LOOKUP_JUMPED;
}
nd->inode = nd->path.dentry->d_inode;
- error = link_path_walk(s, nd);
+ error = link_path_walk(s, nd, flags);
if (unlikely(error))
put_link(nd, link, *p);
}
@@ -1573,7 +1574,8 @@ out_err:
* Without that kind of total limit, nasty chains of consecutive
* symlinks can cause almost arbitrarily long lookups.
*/
-static inline int nested_symlink(struct path *path, struct nameidata *nd)
+static inline int nested_symlink(struct path *path, struct nameidata *nd,
+unsigned int flags)
{
int res;
@@ -1591,7 +1593,7 @@ static inline int nested_symlink(struct path *path,
struct nameidata *nd)
struct path link = *path;
void *cookie;
- res = follow_link(, nd, );
+
[PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
Add a new O_BENEATH_ONLY flag for openat(2) which restricts the
provided path, rejecting (with -EACCES) paths that are not beneath
the provided dfd. In particular, reject:
- paths that contain .. components
- paths that begin with /
- symlinks that have paths as above.
Signed-off-by: David Drysdale drysd...@google.com
---
arch/alpha/include/uapi/asm/fcntl.h | 1 +
arch/parisc/include/uapi/asm/fcntl.h | 1 +
arch/sparc/include/uapi/asm/fcntl.h | 1 +
fs/fcntl.c | 5 +++--
fs/namei.c | 43
fs/open.c| 4 +++-
include/linux/namei.h| 1 +
include/uapi/asm-generic/fcntl.h | 4
8 files changed, 43 insertions(+), 17 deletions(-)
diff --git a/arch/alpha/include/uapi/asm/fcntl.h
b/arch/alpha/include/uapi/asm/fcntl.h
index 09f49a6b87d1..b3e0b00ff9ed 100644
--- a/arch/alpha/include/uapi/asm/fcntl.h
+++ b/arch/alpha/include/uapi/asm/fcntl.h
@@ -33,6 +33,7 @@
#define O_PATH 04000
#define __O_TMPFILE01
+#define O_BENEATH_ONLY 02 /* no / or .. in openat path */
#define F_GETLK7
#define F_SETLK8
diff --git a/arch/parisc/include/uapi/asm/fcntl.h
b/arch/parisc/include/uapi/asm/fcntl.h
index 34a46cbc76ed..da4447775f87 100644
--- a/arch/parisc/include/uapi/asm/fcntl.h
+++ b/arch/parisc/include/uapi/asm/fcntl.h
@@ -21,6 +21,7 @@
#define O_PATH 02000
#define __O_TMPFILE04000
+#define O_BENEATH_ONLY 08000 /* no / or .. in openat path */
#define F_GETLK64 8
#define F_SETLK64 9
diff --git a/arch/sparc/include/uapi/asm/fcntl.h
b/arch/sparc/include/uapi/asm/fcntl.h
index 7e8ace5bf760..9f2635197cf0 100644
--- a/arch/sparc/include/uapi/asm/fcntl.h
+++ b/arch/sparc/include/uapi/asm/fcntl.h
@@ -36,6 +36,7 @@
#define O_PATH 0x100
#define __O_TMPFILE0x200
+#define O_BENEATH_ONLY 0x400 /* no / or .. in openat path */
#define F_GETOWN 5 /* for sockets. */
#define F_SETOWN 6 /* for sockets. */
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 72c82f69b01b..79f9b09fa46b 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -742,14 +742,15 @@ static int __init fcntl_init(void)
* Exceptions: O_NONBLOCK is a two bit define on parisc; O_NDELAY
* is defined as O_NONBLOCK on some platforms and not on others.
*/
- BUILD_BUG_ON(20 - 1 /* for O_RDONLY being 0 */ != HWEIGHT32(
+ BUILD_BUG_ON(21 - 1 /* for O_RDONLY being 0 */ != HWEIGHT32(
O_RDONLY| O_WRONLY | O_RDWR|
O_CREAT | O_EXCL| O_NOCTTY |
O_TRUNC | O_APPEND | /* O_NONBLOCK | */
__O_SYNC| O_DSYNC | FASYNC|
O_DIRECT| O_LARGEFILE | O_DIRECTORY |
O_NOFOLLOW | O_NOATIME | O_CLOEXEC |
- __FMODE_EXEC| O_PATH| __O_TMPFILE
+ __FMODE_EXEC| O_PATH| __O_TMPFILE |
+ O_BENEATH_ONLY
));
fasync_cache = kmem_cache_create(fasync_cache,
diff --git a/fs/namei.c b/fs/namei.c
index 80168273396b..e6b72531dfc7 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -646,7 +646,7 @@ static __always_inline void set_root(struct nameidata *nd)
get_fs_root(current-fs, nd-root);
}
-static int link_path_walk(const char *, struct nameidata *);
+static int link_path_walk(const char *, struct nameidata *, unsigned int);
static __always_inline void set_root_rcu(struct nameidata *nd)
{
@@ -819,7 +819,8 @@ static int may_linkat(struct path *link)
}
static __always_inline int
-follow_link(struct path *link, struct nameidata *nd, void **p)
+follow_link(struct path *link, struct nameidata *nd, unsigned int flags,
+ void **p)
{
struct dentry *dentry = link-dentry;
int error;
@@ -866,7 +867,7 @@ follow_link(struct path *link, struct nameidata *nd, void
**p)
nd-flags |= LOOKUP_JUMPED;
}
nd-inode = nd-path.dentry-d_inode;
- error = link_path_walk(s, nd);
+ error = link_path_walk(s, nd, flags);
if (unlikely(error))
put_link(nd, link, *p);
}
@@ -1573,7 +1574,8 @@ out_err:
* Without that kind of total limit, nasty chains of consecutive
* symlinks can cause almost arbitrarily long lookups.
*/
-static inline int nested_symlink(struct path *path, struct nameidata *nd)
+static inline int nested_symlink(struct path *path, struct nameidata *nd,
+unsigned int flags)
{
int res;
@@ -1591,7 +1593,7 @@ static inline int nested_symlink(struct path *path,
struct nameidata *nd)
struct path link = *path;
void *cookie;
- res =
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Jun 30, 2014 3:36 AM, David Drysdale drysd...@google.com wrote: Add a new O_BENEATH_ONLY flag for openat(2) which restricts the provided path, rejecting (with -EACCES) paths that are not beneath the provided dfd. In particular, reject: - paths that contain .. components - paths that begin with / - symlinks that have paths as above. I like this a lot. However, I think I'd like it even better if it were AT_BENEATH_ONLY so that it could be added to the rest of the *at family. --Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Mon, Jun 30, 2014 at 07:49:41AM -0700, Andy Lutomirski wrote: On Jun 30, 2014 3:36 AM, David Drysdale drysd...@google.com wrote: Add a new O_BENEATH_ONLY flag for openat(2) which restricts the provided path, rejecting (with -EACCES) paths that are not beneath the provided dfd. In particular, reject: - paths that contain .. components - paths that begin with / - symlinks that have paths as above. I like this a lot. However, I think I'd like it even better if it were AT_BENEATH_ONLY so that it could be added to the rest of the *at family. --Andy Wouldn't it need to be both O_BENEATH_ONLY (for openat()) and AT_BENEATH_ONLY (for other *at() functions), like O_NOFOLLOW and AT_SYMLINK_NOFOLLOW? (I.e. aren't the AT_* flags in a different numbering space than O_* flags?) Or am I misunderstanding? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Mon, Jun 30, 2014 at 8:49 AM, David Drysdale drysd...@google.com wrote: On Mon, Jun 30, 2014 at 07:49:41AM -0700, Andy Lutomirski wrote: On Jun 30, 2014 3:36 AM, David Drysdale drysd...@google.com wrote: Add a new O_BENEATH_ONLY flag for openat(2) which restricts the provided path, rejecting (with -EACCES) paths that are not beneath the provided dfd. In particular, reject: - paths that contain .. components - paths that begin with / - symlinks that have paths as above. I like this a lot. However, I think I'd like it even better if it were AT_BENEATH_ONLY so that it could be added to the rest of the *at family. --Andy Wouldn't it need to be both O_BENEATH_ONLY (for openat()) and AT_BENEATH_ONLY (for other *at() functions), like O_NOFOLLOW and AT_SYMLINK_NOFOLLOW? (I.e. aren't the AT_* flags in a different numbering space than O_* flags?) Or am I misunderstanding? Ugh, you're probably right. I wish openat had separate flags and atflags arguments. Oh well. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
David Drysdale drysd...@google.com writes: Add a new O_BENEATH_ONLY flag for openat(2) which restricts the provided path, rejecting (with -EACCES) paths that are not beneath the provided dfd. In particular, reject: - paths that contain .. components - paths that begin with / - symlinks that have paths as above. How about bind mounts? -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2)
On Mon, Jun 30, 2014 at 1:40 PM, Andi Kleen a...@firstfloor.org wrote: David Drysdale drysd...@google.com writes: Add a new O_BENEATH_ONLY flag for openat(2) which restricts the provided path, rejecting (with -EACCES) paths that are not beneath the provided dfd. In particular, reject: - paths that contain .. components - paths that begin with / - symlinks that have paths as above. How about bind mounts? What's the problematic scenario? --Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
