All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
To: Linus Torvalds
	<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Cc: Jann Horn <jannh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-fsdevel
	<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: new ...at() flag: AT_NO_JUMPS
Date: Fri, 5 May 2017 04:00:58 +0100	[thread overview]
Message-ID: <20170505030058.GO29622@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFyOKM7DW7+0sdDFKdZFXgptb5r1id9=Wvhd8AgSP7qjwQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

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 to the actual file it points to.
> 
> So I think that we'd want an additional flag that says "no symlinks at all".

OK, that's easily done.

> And I think the "no mountpoint" traversal might be splittable too.
> 
> Yes, sometimes you'd probably want to say "stay exactly inside this
> filesystem" (like find -xdev). So no arguments against AT_XDEV that
> refuses any mount traversal (kind of like my "no symlink traversal"
> thing).
> 
> But at other points you might want to just guarantee that the walk
> stays below a certain starting point and doesn't escape.
> 
> 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.

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?
2) What should AT_BENEATH | AT_NO_SYMLINKS do on absolute symlinks?  My
preference would be "AT_NO_SYMLINKS wins, ELOOP for you", but that's based
mostly upon the convenience of implementation.
3) What effect should AT_NO_SYMLINKS have upon the final component?  Same
as AT_SYMLINK_NOFOLLOW?

WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jann Horn <jannh@google.com>,
	Linux API <linux-api@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: new ...at() flag: AT_NO_JUMPS
Date: Fri, 5 May 2017 04:00:58 +0100	[thread overview]
Message-ID: <20170505030058.GO29622@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFyOKM7DW7+0sdDFKdZFXgptb5r1id9=Wvhd8AgSP7qjwQ@mail.gmail.com>

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 to the actual file it points to.
> 
> So I think that we'd want an additional flag that says "no symlinks at all".

OK, that's easily done.

> And I think the "no mountpoint" traversal might be splittable too.
> 
> Yes, sometimes you'd probably want to say "stay exactly inside this
> filesystem" (like find -xdev). So no arguments against AT_XDEV that
> refuses any mount traversal (kind of like my "no symlink traversal"
> thing).
> 
> But at other points you might want to just guarantee that the walk
> stays below a certain starting point and doesn't escape.
> 
> 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.

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?
2) What should AT_BENEATH | AT_NO_SYMLINKS do on absolute symlinks?  My
preference would be "AT_NO_SYMLINKS wins, ELOOP for you", but that's based
mostly upon the convenience of implementation.
3) What effect should AT_NO_SYMLINKS have upon the final component?  Same
as AT_SYMLINK_NOFOLLOW?

  parent reply	other threads:[~2017-05-05  3:00 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-29 22:04 new ...at() flag: AT_NO_JUMPS Al Viro
2017-04-29 22:04 ` Al Viro
     [not found] ` <20170429220414.GT29622-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2017-04-29 23:17   ` Andy Lutomirski
2017-04-29 23:17     ` Andy Lutomirski
     [not found]     ` <CALCETrXhOhG0tRDDOROwT9ghvQvKziM2PBN=CX5Soa2m7=0cFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-29 23:25       ` Al Viro
2017-04-29 23:25         ` Al Viro
2017-04-30  1:13         ` Andy Lutomirski
     [not found]         ` <20170429232504.GU29622-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2017-04-30  4:38           ` Matthew Wilcox
2017-04-30  4:38             ` Matthew Wilcox
     [not found]             ` <20170430043822.GE27790-PfSpb0PWhxZc2C7mugBRk2EX/6BAtgUQ@public.gmane.org>
2017-04-30 16:10               ` Al Viro
2017-04-30 16:10                 ` Al Viro
2017-05-01  4:52                 ` Andy Lutomirski
     [not found]                   ` <CALCETrX0dx3d6OQQ+1GJ_xgSz3iNVeRn+8o6b-+3f7awVOWdQg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-01  5:15                     ` Al Viro
2017-05-01  5:15                       ` Al Viro
2017-05-01 17:36 ` Jann Horn
2017-05-01 19:37   ` Andy Lutomirski
     [not found]   ` <CAG48ez0wccvQ5i+XN_Q_yA9_ZwSaGb-W+zky0KQb_GU=9G+MSw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-05  0:30     ` Al Viro
2017-05-05  0:30       ` Al Viro
2017-05-05  0:44       ` Andy Lutomirski
2017-05-05  1:06         ` Al Viro
     [not found]       ` <20170505003030.GM29622-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2017-05-05  1:27         ` Linus Torvalds
2017-05-05  1:27           ` Linus Torvalds
     [not found]           ` <CA+55aFyOKM7DW7+0sdDFKdZFXgptb5r1id9=Wvhd8AgSP7qjwQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-05  3:00             ` Al Viro [this message]
2017-05-05  3:00               ` Al Viro
2017-05-05  4:01               ` Linus Torvalds
2017-05-05  4:31                 ` Andy Lutomirski
2017-05-05  2:47       ` Jann Horn
2017-05-05  3:46         ` Linus Torvalds
     [not found]           ` <CA+55aFy1SokNNUgxBnFLdA1PRyeG13BqyYNg5xVrW-tNGqh2Bg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-05  4:39             ` Al Viro
2017-05-05  4:39               ` Al Viro
2017-05-05  4:44               ` Andy Lutomirski
     [not found]                 ` <CALCETrVQ2fwDZOsGSoLyRb6Qjp4nszfDjOPSYi0kzqt23Aw1NA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-05 20:04                   ` Eric W. Biederman
2017-05-05 20:04                     ` Eric W. Biederman
2017-05-05 20:28               ` Eric W. Biederman
     [not found]                 ` <8737cj6oao.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-05-08 19:34                   ` Mickaël Salaün
2017-05-08 19:34                     ` Mickaël Salaün
2017-05-18  8:50       ` David Drysdale
  -- strict thread matches above, loose matches on Subject: below --
2017-09-10 20:26 Jürg Billeter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170505030058.GO29622@ZenIV.linux.org.uk \
    --to=viro-3bdd1+5odreifsdqtta3olvcufugdwfn@public.gmane.org \
    --cc=jannh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.