Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1643984
| 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 |
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
Re: new ...at() flag: AT_NO_JUMPS David Drysdale <drysdale@google.com> - 2017-05-18 11:00 +0200
csiph-web