Re: new ...at() flag: AT_NO_JUMPS

Hi Al, Might it make sense to specify these lookup restrictions when opening the directory (O_ROOT?) instead of specifying it for each lookup with AT_* (or supporting both)? This might make it more useful when passing directory fds between processes that do not use seccomp (where AT_BENEATH could

Re: new ...at() flag: AT_NO_JUMPS

Hi Al, Might it make sense to specify these lookup restrictions when opening the directory (O_ROOT?) instead of specifying it for each lookup with AT_* (or supporting both)? This might make it more useful when passing directory fds between processes that do not use seccomp (where AT_BENEATH could

Re: new ...at() flag: AT_NO_JUMPS

On Fri, May 5, 2017 at 1:30 AM, Al Viro wrote: > On Mon, May 01, 2017 at 07:36:52PM +0200, Jann Horn wrote: > >> Oh, nice! >> >> It looks like this is somewhat similar to the old O_BENEATH proposal, >> but because the intentions behind the proposals are different >>

Re: new ...at() flag: AT_NO_JUMPS

On Fri, May 5, 2017 at 1:30 AM, Al Viro wrote: > On Mon, May 01, 2017 at 07:36:52PM +0200, Jann Horn wrote: > >> Oh, nice! >> >> It looks like this is somewhat similar to the old O_BENEATH proposal, >> but because the intentions behind the proposals are different >> (application sandboxing versus

Re: new ...at() flag: AT_NO_JUMPS

On 05/05/2017 22:28, Eric W. Biederman wrote: > Al Viro writes: > >> On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote: >>> On Thu, May 4, 2017 at 7:47 PM, Jann Horn wrote: Thread 1 starts an AT_BENEATH path walk using an O_PATH

Re: new ...at() flag: AT_NO_JUMPS

On 05/05/2017 22:28, Eric W. Biederman wrote: > Al Viro writes: > >> On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote: >>> On Thu, May 4, 2017 at 7:47 PM, Jann Horn wrote: Thread 1 starts an AT_BENEATH path walk using an O_PATH fd pointing to

Re: new ...at() flag: AT_NO_JUMPS

Al Viro writes: > On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote: >> On Thu, May 4, 2017 at 7:47 PM, Jann Horn wrote: >> > >> > Thread 1 starts an AT_BENEATH path walk using an O_PATH fd >> > pointing to /srv/www/example.org/foo; the

Re: new ...at() flag: AT_NO_JUMPS

Al Viro writes: > On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote: >> On Thu, May 4, 2017 at 7:47 PM, Jann Horn wrote: >> > >> > Thread 1 starts an AT_BENEATH path walk using an O_PATH fd >> > pointing to /srv/www/example.org/foo; the path given to the syscall is >> >

Re: new ...at() flag: AT_NO_JUMPS

Andy Lutomirski writes: > On Thu, May 4, 2017 at 9:39 PM, Al Viro wrote: >> On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote: >>> On Thu, May 4, 2017 at 7:47 PM, Jann Horn wrote: >>> > >>> > Thread 1 starts an AT_BENEATH

Re: new ...at() flag: AT_NO_JUMPS

Andy Lutomirski writes: > On Thu, May 4, 2017 at 9:39 PM, Al Viro wrote: >> On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote: >>> On Thu, May 4, 2017 at 7:47 PM, Jann Horn wrote: >>> > >>> > Thread 1 starts an AT_BENEATH path walk using an O_PATH fd >>> > pointing to

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 4, 2017 at 9:39 PM, Al Viro wrote: > On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote: >> On Thu, May 4, 2017 at 7:47 PM, Jann Horn wrote: >> > >> > Thread 1 starts an AT_BENEATH path walk using an O_PATH fd >> > pointing to

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 4, 2017 at 9:39 PM, Al Viro wrote: > On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote: >> On Thu, May 4, 2017 at 7:47 PM, Jann Horn wrote: >> > >> > Thread 1 starts an AT_BENEATH path walk using an O_PATH fd >> > pointing to /srv/www/example.org/foo; the path given to

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote: > On Thu, May 4, 2017 at 7:47 PM, Jann Horn wrote: > > > > Thread 1 starts an AT_BENEATH path walk using an O_PATH fd > > pointing to /srv/www/example.org/foo; the path given to the syscall is > >

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote: > On Thu, May 4, 2017 at 7:47 PM, Jann Horn wrote: > > > > Thread 1 starts an AT_BENEATH path walk using an O_PATH fd > > pointing to /srv/www/example.org/foo; the path given to the syscall is > > "bar/../../../../etc/passwd". The

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 4, 2017 at 9:01 PM, Linus Torvalds wrote: > On Thu, May 4, 2017 at 8:00 PM, Al Viro wrote: >>> >>> That could still allow crossing mount-points, but only if they are >>> non-bind mounts and cannot let us escape. >>> >>> I'm not

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 4, 2017 at 9:01 PM, Linus Torvalds wrote: > On Thu, May 4, 2017 at 8:00 PM, Al Viro wrote: >>> >>> That could still allow crossing mount-points, but only if they are >>> non-bind mounts and cannot let us escape. >>> >>> I'm not sure if that's testable, though. >> >> This one isn't,

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 4, 2017 at 8:00 PM, Al Viro wrote: >> >> That could still allow crossing mount-points, but only if they are >> non-bind mounts and cannot let us escape. >> >> I'm not sure if that's testable, though. > > This one isn't, unfortunately - there is no difference

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 4, 2017 at 8:00 PM, Al Viro wrote: >> >> That could still allow crossing mount-points, but only if they are >> non-bind mounts and cannot let us escape. >> >> I'm not sure if that's testable, though. > > This one isn't, unfortunately - there is no difference between bind and >

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 4, 2017 at 7:47 PM, Jann Horn wrote: > > Thread 1 starts an AT_BENEATH path walk using an O_PATH fd > pointing to /srv/www/example.org/foo; the path given to the syscall is > "bar/../../../../etc/passwd". The path walk enters the "bar" directory. > Thread 2 moves

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 4, 2017 at 7:47 PM, Jann Horn wrote: > > Thread 1 starts an AT_BENEATH path walk using an O_PATH fd > pointing to /srv/www/example.org/foo; the path given to the syscall is > "bar/../../../../etc/passwd". The path walk enters the "bar" directory. > Thread 2 moves

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 04, 2017 at 06:27:10PM -0700, Linus Torvalds wrote: > As mentioned last time, at least for the git usage, even relative > symlinks are a no-no - not because they'd escape, but simply because > git wants to see the *unique* name, and resolve relative symlinks to > either the symlink,

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 04, 2017 at 06:27:10PM -0700, Linus Torvalds wrote: > As mentioned last time, at least for the git usage, even relative > symlinks are a no-no - not because they'd escape, but simply because > git wants to see the *unique* name, and resolve relative symlinks to > either the symlink,

Re: new ...at() flag: AT_NO_JUMPS

+CC drysdale in case he has thoughts on this On Fri, May 5, 2017 at 2:30 AM, Al Viro wrote: > On Mon, May 01, 2017 at 07:36:52PM +0200, Jann Horn wrote: > >> Oh, nice! >> >> It looks like this is somewhat similar to the old O_BENEATH proposal, >> but because the

Re: new ...at() flag: AT_NO_JUMPS

+CC drysdale in case he has thoughts on this On Fri, May 5, 2017 at 2:30 AM, Al Viro wrote: > On Mon, May 01, 2017 at 07:36:52PM +0200, Jann Horn wrote: > >> Oh, nice! >> >> It looks like this is somewhat similar to the old O_BENEATH proposal, >> but because the intentions behind the proposals

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 4, 2017 at 5:30 PM, Al Viro wrote: > > As for mountpoint crossing... it might make sense to split those. > O_BENEATH allowed it, and if we want AT_BENEATH to match that - let's > do it. Then this one would become AT_BENEATH | AT_XDEV (the latter named >

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 4, 2017 at 5:30 PM, Al Viro wrote: > > As for mountpoint crossing... it might make sense to split those. > O_BENEATH allowed it, and if we want AT_BENEATH to match that - let's > do it. Then this one would become AT_BENEATH | AT_XDEV (the latter named > after find(1) option,

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 04, 2017 at 05:44:19PM -0700, Andy Lutomirski wrote: > > It's not quite O_BENEATH, and IMO it's saner that way - a/b/c/../d is > > bloody well allowed, and so are relative symlinks that do not lead out of > > the subtree. If somebody has a good argument in favour of flat-out > > ban

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 04, 2017 at 05:44:19PM -0700, Andy Lutomirski wrote: > > It's not quite O_BENEATH, and IMO it's saner that way - a/b/c/../d is > > bloody well allowed, and so are relative symlinks that do not lead out of > > the subtree. If somebody has a good argument in favour of flat-out > > ban

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 4, 2017 at 5:30 PM, Al Viro wrote: > On Mon, May 01, 2017 at 07:36:52PM +0200, Jann Horn wrote: > >> Oh, nice! >> >> It looks like this is somewhat similar to the old O_BENEATH proposal, >> but because the intentions behind the proposals are different >>

Re: new ...at() flag: AT_NO_JUMPS

On Thu, May 4, 2017 at 5:30 PM, Al Viro wrote: > On Mon, May 01, 2017 at 07:36:52PM +0200, Jann Horn wrote: > >> Oh, nice! >> >> It looks like this is somewhat similar to the old O_BENEATH proposal, >> but because the intentions behind the proposals are different >> (application sandboxing versus

Re: new ...at() flag: AT_NO_JUMPS

On Mon, May 01, 2017 at 07:36:52PM +0200, Jann Horn wrote: > Oh, nice! > > It looks like this is somewhat similar to the old O_BENEATH proposal, > but because the intentions behind the proposals are different > (application sandboxing versus permitting an application to restrict its > own

Re: new ...at() flag: AT_NO_JUMPS

On Mon, May 01, 2017 at 07:36:52PM +0200, Jann Horn wrote: > Oh, nice! > > It looks like this is somewhat similar to the old O_BENEATH proposal, > but because the intentions behind the proposals are different > (application sandboxing versus permitting an application to restrict its > own

Re: new ...at() flag: AT_NO_JUMPS

On Mon, May 1, 2017 at 10:36 AM, Jann Horn <ja...@google.com> wrote: > On Sun, Apr 30, 2017 at 12:04 AM, Al Viro <v...@zeniv.linux.org.uk> wrote: >> New AT_... flag - AT_NO_JUMPS >> >> Semantics: pathname resolution must not involve >>

Re: new ...at() flag: AT_NO_JUMPS

On Mon, May 1, 2017 at 10:36 AM, Jann Horn wrote: > On Sun, Apr 30, 2017 at 12:04 AM, Al Viro wrote: >> New AT_... flag - AT_NO_JUMPS >> >> Semantics: pathname resolution must not involve >> * traversals of absolute symlinks >> * tr

Re: new ...at() flag: AT_NO_JUMPS

On Sun, Apr 30, 2017 at 12:04 AM, Al Viro <v...@zeniv.linux.org.uk> wrote: > New AT_... flag - AT_NO_JUMPS > > Semantics: pathname resolution must not involve > * traversals of absolute symlinks > * traversals of procfs-style symlinks > * t

Re: new ...at() flag: AT_NO_JUMPS

On Sun, Apr 30, 2017 at 12:04 AM, Al Viro wrote: > New AT_... flag - AT_NO_JUMPS > > Semantics: pathname resolution must not involve > * traversals of absolute symlinks > * traversals of procfs-style symlinks > * traversals of mountpoints (including b

Re: new ...at() flag: AT_NO_JUMPS

On Sun, Apr 30, 2017 at 09:52:37PM -0700, Andy Lutomirski wrote: > On Sun, Apr 30, 2017 at 9:10 AM, Al Viro wrote: > > On Sat, Apr 29, 2017 at 09:38:22PM -0700, Matthew Wilcox wrote: > > > >> It sounds more like AT_NO_ESCAPE ... or AT_BELOW, or something. > > > > I

Re: new ...at() flag: AT_NO_JUMPS

On Sun, Apr 30, 2017 at 09:52:37PM -0700, Andy Lutomirski wrote: > On Sun, Apr 30, 2017 at 9:10 AM, Al Viro wrote: > > On Sat, Apr 29, 2017 at 09:38:22PM -0700, Matthew Wilcox wrote: > > > >> It sounds more like AT_NO_ESCAPE ... or AT_BELOW, or something. > > > > I considered AT_ROACH_MOTEL at

Re: new ...at() flag: AT_NO_JUMPS

On Sun, Apr 30, 2017 at 9:10 AM, Al Viro wrote: > On Sat, Apr 29, 2017 at 09:38:22PM -0700, Matthew Wilcox wrote: > >> It sounds more like AT_NO_ESCAPE ... or AT_BELOW, or something. > > I considered AT_ROACH_MOTEL at one point... Another interesting > question is

Re: new ...at() flag: AT_NO_JUMPS

On Sun, Apr 30, 2017 at 9:10 AM, Al Viro wrote: > On Sat, Apr 29, 2017 at 09:38:22PM -0700, Matthew Wilcox wrote: > >> It sounds more like AT_NO_ESCAPE ... or AT_BELOW, or something. > > I considered AT_ROACH_MOTEL at one point... Another interesting > question is whether EXDEV would've been

Re: new ...at() flag: AT_NO_JUMPS

On Sat, Apr 29, 2017 at 09:38:22PM -0700, Matthew Wilcox wrote: > It sounds more like AT_NO_ESCAPE ... or AT_BELOW, or something. I considered AT_ROACH_MOTEL at one point... Another interesting question is whether EXDEV would've been better than ELOOP. Opinions?

Re: new ...at() flag: AT_NO_JUMPS

On Sat, Apr 29, 2017 at 09:38:22PM -0700, Matthew Wilcox wrote: > It sounds more like AT_NO_ESCAPE ... or AT_BELOW, or something. I considered AT_ROACH_MOTEL at one point... Another interesting question is whether EXDEV would've been better than ELOOP. Opinions?

Re: new ...at() flag: AT_NO_JUMPS

On Sun, Apr 30, 2017 at 12:25:04AM +0100, Al Viro wrote: > On Sat, Apr 29, 2017 at 04:17:18PM -0700, Andy Lutomirski wrote: > > On Sat, Apr 29, 2017 at 3:04 PM, Al Viro <v...@zeniv.linux.org.uk> wrote: > > > New AT_... flag - AT_NO_JUMPS > > > > > > Seman

Re: new ...at() flag: AT_NO_JUMPS

On Sun, Apr 30, 2017 at 12:25:04AM +0100, Al Viro wrote: > On Sat, Apr 29, 2017 at 04:17:18PM -0700, Andy Lutomirski wrote: > > On Sat, Apr 29, 2017 at 3:04 PM, Al Viro wrote: > > > New AT_... flag - AT_NO_JUMPS > > > > > > Semantics:

Re: new ...at() flag: AT_NO_JUMPS

On Sat, Apr 29, 2017 at 4:25 PM, Al Viro <v...@zeniv.linux.org.uk> wrote: > On Sat, Apr 29, 2017 at 04:17:18PM -0700, Andy Lutomirski wrote: >> On Sat, Apr 29, 2017 at 3:04 PM, Al Viro <v...@zeniv.linux.org.uk> wrote: >> > New AT_... flag - AT_NO_JUMPS >> > &

Re: new ...at() flag: AT_NO_JUMPS

On Sat, Apr 29, 2017 at 4:25 PM, Al Viro wrote: > On Sat, Apr 29, 2017 at 04:17:18PM -0700, Andy Lutomirski wrote: >> On Sat, Apr 29, 2017 at 3:04 PM, Al Viro wrote: >> > New AT_... flag - AT_NO_JUMPS >> > >> > Semantics: pathname resolution must not involve &

Re: new ...at() flag: AT_NO_JUMPS

On Sat, Apr 29, 2017 at 04:17:18PM -0700, Andy Lutomirski wrote: > On Sat, Apr 29, 2017 at 3:04 PM, Al Viro <v...@zeniv.linux.org.uk> wrote: > > New AT_... flag - AT_NO_JUMPS > > > > Semantics: pathname resolution must not involve > >

Re: new ...at() flag: AT_NO_JUMPS

On Sat, Apr 29, 2017 at 04:17:18PM -0700, Andy Lutomirski wrote: > On Sat, Apr 29, 2017 at 3:04 PM, Al Viro wrote: > > New AT_... flag - AT_NO_JUMPS > > > > Semantics: pathname resolution must not involve > > * traversals of absolute symlinks > >

Re: new ...at() flag: AT_NO_JUMPS

On Sat, Apr 29, 2017 at 3:04 PM, Al Viro <v...@zeniv.linux.org.uk> wrote: > New AT_... flag - AT_NO_JUMPS > > Semantics: pathname resolution must not involve > * traversals of absolute symlinks > * traversals of procfs-style symlinks > * traversals o

Re: new ...at() flag: AT_NO_JUMPS

On Sat, Apr 29, 2017 at 3:04 PM, Al Viro wrote: > New AT_... flag - AT_NO_JUMPS > > Semantics: pathname resolution must not involve > * traversals of absolute symlinks > * traversals of procfs-style symlinks > * traversals of mountpoints (including bindin

new ...at() flag: AT_NO_JUMPS

New AT_... flag - AT_NO_JUMPS Semantics: pathname resolution must not involve * traversals of absolute symlinks * traversals of procfs-style symlinks * traversals of mountpoints (including bindings, referrals, etc.) * traversal of .. in the starting point

new ...at() flag: AT_NO_JUMPS

New AT_... flag - AT_NO_JUMPS Semantics: pathname resolution must not involve * traversals of absolute symlinks * traversals of procfs-style symlinks * traversals of mountpoints (including bindings, referrals, etc.) * traversal of .. in the starting point