Fw: [RFC] AT_NO_JUMPS/LOOKUP_NO_JUMPS

[Martin Schwenke]

I was pointed to this thread on LKML by someone wondering if the topic
being discussed is important to Samba.  I also have the original
message from Al Viro, if someone wants me to forward it to them.

peace & happiness,
martin


Begin forwarded message:

From: Linus Torvalds <torvalds at linux-foundation.org>
To: Al Viro <viro at zeniv.linux.org.uk>
Cc: Linux Kernel Mailing List <linux-kernel at vger.kernel.org>,         linux-fsdevel <linux-fsdevel at vger.kernel.org>
Subject: Re: [RFC] AT_NO_JUMPS/LOOKUP_NO_JUMPS
Date: Sun, 19 Mar 2017 18:46:01 -0700

On Sun, Mar 19, 2017 at 10:24 AM, Al Viro <viro at zeniv.linux.org.uk>
wrote:
>         Bringing back an old conversation - what do you think about the
> potential usefulness of the following ...at() option:
>         * no mountpoint crossings allowed (mount --bind included)
>         * only relative symlinks traversals are allowed
>         * starting point acts as a chroot boundary (IOW, .. does not lead
> out of it)  

Hmm. The original use of this was iirc apache (or maybe samba), that
simply wanted to be sure that when you did a pathname lookup, it
didn't escape out of the subtree that the lookup was done from (eg
some public_html directory or whatever).

But I had that discussions *long* ago, and I don't even remember who
it might have been with. My reaction at the time was simply that it
would have been easy for us to have a "no symlink traversal at all"
mode, because their solution was to just walk each path component
carefully by hand.

Maybe somebody who knows apache (or samba) can pipe up and say "yeah,
we still do that", or "we solved it with our own filename cache, so we
don't care".

> IIRC, you mentioned that something of that kind might be interesting for
> git et.al. and it turns out to be surprisingly easy to implement -  

So for git, we have a notion of "real path", and your thing doesn't
solve that, because it really is "return the actual canonical path to
the filename given by xyz".

And _usually_ the real path of xyz is trivially xyz. But if xyz
contains a symlink, or if xyz contains a "..", that gets resolved. But
that needs to happen even *if* the path stays inside the project.

So git *could* make use of something that errored out for anything
that wasn't canonical: that includes using "." and "" in the pathname,
btw, but also symlinks and "..".

That would meke the "realpath()" logic be:

 - try to look it up using the "strict canonical case only", and if
that succeeds, we just return the original pathname

 - otherwise do the per-component lookup and fix it up manually.

So for git, escaping the subdirectory is only one small issue, and
your patch wouldn't be sufficient because it still allows symlinks
that don't escape the tree.

(Also, honestly, I don't think it's ever a real performance issue, and
since git would need to have the fallback code to do the resolution
anyway, it doesn't help from a complexity standpoint either).

So I don't think the patch is interesting for git at least as-is, and
because of complexity and portability, possibly not even if it did add
a flag to always error out on the special path components of "", ".",
"..", and symlinks.

I think the concept makes sense, and we might well want to encourage
it as a way for people to efficiently and easily verify that the end
result of a lookup stays inside a certain directory structure, but I
think we'd want to have a champion of this feature that would actually
use it.

Maybe somebody on fsdevel knows of a particular load that is
performance-critical and important for some group of people, and
currently looks up pathnames component by component because of issues
like this..

Anybody?

                        Linus
-------------- next part --------------
An embedded message was scrubbed...
From: Linus Torvalds <torvalds at linux-foundation.org>
Subject: Re: [RFC] AT_NO_JUMPS/LOOKUP_NO_JUMPS
Date: Sun, 19 Mar 2017 18:46:01 -0700
Size: 6418
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170320/7040c5a5/attachment.mht>