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

Groups > linux.kernel > #1636156

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

Show all headers | View raw

On Thu, May 4, 2017 at 9:01 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, May 4, 2017 at 8:00 PM, Al Viro <viro@zeniv.linux.org.uk> 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; vfsmounts form a tree and both normal mount and bind add leaves
>> to it.  Moreover, mount -t ext2 /dev/sdc7 /mnt; mount -t ext2 /dev/sdc7 /tmp/a
>> yield the same state as mount -t ext2 /dev/sdc7; mount --bind /mnt /tmp/a.
>> There is no way to tell the difference, simply because there *is* no
>> difference.  Moreover, either can be followed by umount /mnt and you'll get
>> the same state as you would have after a solitary mount of the same fs on
>> /tmp/a.
>
> Fair enough.
>
>> Ho-hum...  So:
>>
>>                         AT_BENEATH      AT_XDEV         AT_NO_SYMLINKS
>> absolute pathname:      EXDEV
>> non-relative symlink:   EXDEV           ?               ELOOP
>> relative symlink:                                       ELOOP
>> .. from starting point: EXDEV
>> .. crossing mountpoint:                 EXDEV
>> crossing into mountpoint:               EXDEV
>>
>> 1) What should AT_XDEV do about absolute symlinks?  Nothing special?  EXDEV?
>> EXDEV if we are not on root?
>
> My mental model would say that AT_XDEV without AT_BENEATH would
> _logically_ result in "EXDEV if / is a different vfsmount", accept the
> absolute path otherwise.
>
> But honestly, just returning EXDEV unconditionally for an absolute
> symlink might just be the simpler and more straightforward thing to
> do.
>
> Because testing the particular vfsmount of / simply doesn't seem to be
> a very useful operation.  I dunno.

My intuition is that, regardless of whether it's obviously useful to
test the vfsmount, we should allow / if it's the same mount for
orthogonality and because it seems more likely to be the expected
behavior.

>
>> 3) What effect should AT_NO_SYMLINKS have upon the final component?  Same
>> as AT_SYMLINK_NOFOLLOW?
>
> I actually would suggest "error if it's followed".
>
> So if you use AT_SYMLINK_NOFOLLOW | AT_NO_SYMLINKS, then you do *not*
> get an error if the last component (but nothing before it) is a
> symlink, and the end result is the symlink itself.
>
> If you use just AT_NO_SYMLINKS, then the lack of NOFOLLOW implies that
> you'd follow the symlink to look it up, and then AT_NO_SYMLINKS means
> that you get an error (ELOOP).
>
> So the user gets to choose, and gets to basically indicate whether
> it's fine to end at a dangling symlink or not. Which is exactly what
> AT_SYMLINK_NOFOLLOW is all about.

Sounds reasonable to me.

--Andy

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

Thread

new ...at() flag: AT_NO_JUMPS Al Viro <viro@ZenIV.linux.org.uk> - 2017-04-30 00:10 +0200
  Re: new ...at() flag: AT_NO_JUMPS Andy Lutomirski <luto@kernel.org> - 2017-04-30 01:20 +0200
    Re: new ...at() flag: AT_NO_JUMPS Al Viro <viro@ZenIV.linux.org.uk> - 2017-04-30 01:30 +0200
      Re: new ...at() flag: AT_NO_JUMPS Andy Lutomirski <luto@kernel.org> - 2017-04-30 03:20 +0200
      Re: new ...at() flag: AT_NO_JUMPS Matthew Wilcox <willy@infradead.org> - 2017-04-30 06:40 +0200
        Re: new ...at() flag: AT_NO_JUMPS Al Viro <viro@ZenIV.linux.org.uk> - 2017-04-30 18:20 +0200
          Re: new ...at() flag: AT_NO_JUMPS Andy Lutomirski <luto@kernel.org> - 2017-05-01 07:00 +0200
            Re: new ...at() flag: AT_NO_JUMPS Al Viro <viro@ZenIV.linux.org.uk> - 2017-05-01 07:20 +0200
  Re: new ...at() flag: AT_NO_JUMPS Jann Horn <jannh@google.com> - 2017-05-01 19:40 +0200
    Re: new ...at() flag: AT_NO_JUMPS Andy Lutomirski <luto@kernel.org> - 2017-05-01 21:40 +0200
    Re: new ...at() flag: AT_NO_JUMPS Al Viro <viro@ZenIV.linux.org.uk> - 2017-05-05 02:40 +0200
      Re: new ...at() flag: AT_NO_JUMPS Andy Lutomirski <luto@kernel.org> - 2017-05-05 02:50 +0200
        Re: new ...at() flag: AT_NO_JUMPS Al Viro <viro@ZenIV.linux.org.uk> - 2017-05-05 03:10 +0200
      Re: new ...at() flag: AT_NO_JUMPS Linus Torvalds <torvalds@linux-foundation.org> - 2017-05-05 03:30 +0200
        Re: new ...at() flag: AT_NO_JUMPS Al Viro <viro@ZenIV.linux.org.uk> - 2017-05-05 05:10 +0200
          Re: new ...at() flag: AT_NO_JUMPS Linus Torvalds <torvalds@linux-foundation.org> - 2017-05-05 06:10 +0200
            Re: new ...at() flag: AT_NO_JUMPS Andy Lutomirski <luto@kernel.org> - 2017-05-05 06:40 +0200
      Re: new ...at() flag: AT_NO_JUMPS Jann Horn <jannh@google.com> - 2017-05-05 04:50 +0200
        Re: new ...at() flag: AT_NO_JUMPS Linus Torvalds <torvalds@linux-foundation.org> - 2017-05-05 05:50 +0200
          Re: new ...at() flag: AT_NO_JUMPS Al Viro <viro@ZenIV.linux.org.uk> - 2017-05-05 06:40 +0200
            Re: new ...at() flag: AT_NO_JUMPS Andy Lutomirski <luto@kernel.org> - 2017-05-05 06:50 +0200
              Re: new ...at() flag: AT_NO_JUMPS ebiederm@xmission.com (Eric W. Biederman) - 2017-05-05 22:20 +0200
            Re: new ...at() flag: AT_NO_JUMPS ebiederm@xmission.com (Eric W. Biederman) - 2017-05-05 22:40 +0200
              Re: new ...at() flag: AT_NO_JUMPS Mickaël Salaün <mic@digikod.net> - 2017-05-08 21:40 +0200

csiph-web