Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1643984

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

From David Drysdale <drysdale@google.com>
Newsgroups linux.kernel
Subject Re: new ...at() flag: AT_NO_JUMPS
Date 2017-05-18 11:00 +0200
Message-ID <tIprP-7UI-3@gated-at.bofh.it> (permalink)
References <tBIIW-3pv-3@gated-at.bofh.it> <tCnsK-3AJ-13@gated-at.bofh.it> <tDzrQ-2sC-15@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri, May 5, 2017 at 1:30 AM, Al Viro <viro@zeniv.linux.org.uk> 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 permitting an application to restrict its
>> own filesystem accesses), the semantics differ: AT_NO_JUMPS
>> doesn't prevent starting the path with "/", but does prevent mountpoint
>> traversal. Is that correct?
>
> It prevents both, actually - I missed that in description, but this
>         if (unlikely(nd->flags & LOOKUP_NO_JUMPS))
>                 return -ELOOP;
> in nd_jump_root() affects absolute pathnames same way as it affects
> absolute symlinks.
>
> 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 on .. (_other_ than "other guys do it that way, and it doesn't need
> to make sense 'cuz security!!1!!!", please), I'd be glad to hear it.

BTW, FreeBSD head now allows .. if it stays in subtree:
https://svnweb.freebsd.org/base?view=revision&revision=308212

Back to linux.kernel | Previous | Next | Find similar | Unroll thread


Thread

Re: new ...at() flag: AT_NO_JUMPS David Drysdale <drysdale@google.com> - 2017-05-18 11:00 +0200

csiph-web