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

[Andy Lutomirski]

On Thu, May 4, 2017 at 9:01 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, May 4, 2017 at 8:00 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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