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
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
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 /srv/www/example.org/fo
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
>> > "bar/../../.
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 /srv/www/exam
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 th
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 pat
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, un
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
> no-bind;
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 /srv/www/example.org/f
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, or
+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 ar
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, obviousl
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 on
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
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 filesys
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
>> * traversals of procfs-style symlinks
>> * tr
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 bindings, referrals, etc
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 one
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 bett
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?
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: pathname resolution must not involve
> > > * traversals
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
>> > * traversals of absolute
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
> > * traversals of procfs-style symlin
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 bindings, referrals, etc.
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 of pathnam
26 matches
Mail list logo
