Re: firmlink deleting files on boot / interpretation of find -xdev switch

[Olaf Buddenhagen]

Hi,

On Mon, Sep 05, 2016 at 09:55:44PM -1000, Brent W. Baccala wrote:
> On Thu, Sep 1, 2016 at 12:38 PM, Richard Braun <rbraun@sceen.net> wrote:

> > This was famously shown with the example of the
> > firmlink translator used in /tmp, which would cause the removal of
> > any file targeted by the firmlink on /tmp cleanup during system
> > startup.
>
> I see that.  It seems to still have that problem.  I created a directory
> /root/baitdir, and put in it a file named 'bait'.  As a non-privileged
> user, I created a firmlink in /tmp to /root/baitdir and rebooted.  Voila!
> 'bait' vanished.
> 
> I took the time to read some of this mailing list's archive on the
> subject.  The consensus seems to be that you can't trust unprivileged
> translators.  So "find", which is used to clean /tmp, should not, in this
> case, cross translator boundaries.

I don't know which threads you have read exactly; but there have been
pretty conclusive discussions on this issue IMHO.

The "quickfix" solution is simply by default not to follow translators
running with a different UID than the client. (Unless the translator is
running as root.) That's pretty much what FUSE does on Linux.

A more ambitious solution I came up with Carl is to change the reauth
mechanism: when crossing translator boundaries during a lookup, instead
of obtaining an new auth token associated with all of the IDs available
to the client process, we would create an auth token associated with
only the intersection of the IDs from the previous auth token, and the
IDs available to the new translator we are entering. This way, when for
example a root process follows a firmlink run by an ordinary user, it
would get an auth token associated with only that user's IDs, not the
root IDs; and when the firmlink redirects to some other FS location, the
following lookup would still be limited to that user's IDs -- so the FD
obtained from the lookup could not be used to delete a file that the
untrusted user has no permissions for.

> I was thinking at first that we should have something like the "-xdev"
> switch; "-xtrans", maybe?

Selecting how to treat translators in general is another long-standing
issue, but with a broader and somewhat different scope than the trust
issue. Backups are a pretty illustrative standard example for that.

The fundamental problem with this is that translators range from things
that behave and should be treated like traditional filesystem mounts, to
others that should be pretty much transparent -- trying to treat all of
them in the same manner is bound to create problems in one situation or
the other. We need a more fine-grained solution.

Trying to add options to handle all the possible cases to all relevant
client programs is not realistic. Thus the solution I advocate instead
is something I refer to as "namespace-based translator selection": the
user adds special suffixes to paths, which are transparent to the
clients doing the lookup, but invoke special handling in the lookup
mechanism. Thus for example "rm -r /foo,,*" would follow all
translators, while "rm -r /foo,,0" wouldn't follow any; yet other
options could be more selective, following only certain classes of
translators etc.

Many years ago Sergiu worked on a prototype implementation we called
"nsmux" (for lack of a more suitable name) in the context of a GSoC
project (kinda), and we got many in-depth discussion along with a
partially working implementation. It didn't get finished, because the
implementation as a proxy server turned out more involved than initially
anticipated (the other option would be implementing it in glibc); and
also because I wasn't able to keep up with the amount of mentoring
necessary I think... But the idea is still out there.

(My favourite feature of this mechanism is the ability to specify
"dynamic" translators to be applied during the lookup, without a need to
explicitly set them up first; so we could for example do something like
"vi /foo/bar.gz,,unzip" -- I believe this would really give the Hurd an
edge in convenience over other systems...)

> Yet since filesystem mounts are themselves done with translators, what does
> "-xdev" mean on Hurd?  I've poked around a bit in the source, and played
> with 'stat'.  It seems like several translators take an arbitrary number
> and present it as their device number.  Seems like legacy support, and it's
> easy for a translator to defeat -xdev by announcing the same device as its
> parent.

This is actually an interesting idea for a partial solution: we could
introduce some mechanism that would allow specifying (e.g. as an option
to settrans) whether a translator should be transparent or mount-like;
which would determine whether the translator is allowed to claim the
same device ID as its parent or not. That would require some major
interface changes in the Hurd -- but it might be worth the effort.

> On a related note, how do you find the owner of a passive translator?  I
> expected either showtrans or ls to provide that information (perhaps with a
> verbose switch), but it had eluded me...

What exactly do you mean here? The translator record itself doesn't have
a distinct owner -- the record can only be set by the owner of the FS
node in question though (or root); and an active translator stared from
it is run with the UID of same user.

-antrik-