Re: [PATCH 0/3] vfs: plug some holes involving LAST_BIND symlinksand file bind mounts (try #5)

[Jeff Layton]

On Tue, 24 Nov 2009 01:20:27 +0000
Jamie Lokier <jamie@xxxxxxxxxxxxx> wrote:

> Jeff Layton wrote:
> > I certainly don't want to break existing apps. That said, applications
> > that are depending on /proc/pid symlinks to allow them to bypass
> > directory permissions or access files that aren't in their namespace
> > would seem to be unsafe, no?
> 
> I think we can mostly agree on that :-)
> 
> > I think all we can reasonably do is try to clearly lay out how these
> > symlinks are intended to work. I think it's logical that the result of
> > following these links should be more or less the same as if you were to
> > resolve the results of the readlink.
> > 
> > Is there some reason that we should expect them to provide anything
> > more? Do you have apps in mind that you think will break with this
> > change?
> 
> Anything which compiled with and uses the openat(), mkdirat()
> etc. emulation in gnulib (formerly known as libiberty), and anything
> using the same technique.
> 
> You know, GNU coreutils and other obscure things :-)
> 
> Of course there are real system calls for that, now, but there are
> still compiled programs that don't know about the real system calls.
> 
> The same technique (traversing /proc/self/fd/N) is used on Solaris, by
> the way.  It's probably worth keeping a modicum of compatibility with
> whatever Solaris does.
> 

Oof...ok. I didn't realize that these symlinks were relied on in such a
fashion. I guess that means that there is a need to have them continue
to have special semantics beyond what a symlink would ordinarily have.

> > If you think this is unreasonable, perhaps you could suggest an
> > alternative?
> 
> I have, two mails up - did you read it? - and in the previous threads
> which resulted in the bugtraq.
> 
> Please tell me why that approach does not work, thanks.
> 

I did read it, sorry I didn't comment on it before...

My immediate thought was that that approach only affects open calls. If
the containing directory weren't executable by the process it wouldn't
be able to (for instance) stat the file were these symlinks more
ordinary. Of course, the process could always do an fstat on the fd so
I don't suppose there's any harm in allowing it.

Since it's clear that these symlinks do need to have special semantics,
perhaps the approach you suggest would be the best thing. I'll have to
think about it a bit more.

> > If this approach is reasonable, there is one thing I think that I'm
> > pretty sure will need to be fixed.
> 
> It's not reasonable for /proc/self/fd/N because that has historically
> been a way to follow a directory (like openat) or dup() an open file
> without sharing the seek offset, which is useful for multithreaded
> code.
> 
> Same goes for /proc/self/exe: That has historically been a way to read
> your own executable, e.g. for self-extracting executables, executables
> with additional data glued on.  That breaks if the executable at the
> link target is not yourself.
> 
> But just to prove we've been over this before and never came to a
> consensus or conclusion:
> 
> http://lkml.org/lkml/2008/3/23/3
> 
> (the whole thread is worth a read, but Denys Vlasenko's remarks are
> especially relevant).
> 
> And for those who remember 2.0 :-)
> 
> http://lkml.indiana.edu/hypermail/linux/kernel/9609.2/0371.html
> 

Thanks for the links. Those help clarify where you and Eric are coming
from. I'll need to rethink this.

Thank you (and Eric) for the comments so far.

Cheers,
-- 
Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/