Re: Shadowfs - some notes

[Roland McGrath]

> However, this assumes that shadowfs always has at least the permissions of
> the user.  If for example root wants to create a directory, he can not do it
> through shadowfs if it runs as a user, he will not be able to do it through
> shadowfs, right?  Not that this is a big problem, as root is always able to
> get at the underlying filesystems (at least theoretically).

This is not particular to shadowfs, this is an issue with any translator.
The translator, a process owned by some user joebob, is deciding what fs
calls to make where.  So security demands that it not be able to usurp a
client's privilege for those calls, as would be required for joebob's
translator to create a file or directory owned by root.  I would argue that
even if we had a user-retries interface as Moritz suggested instead of
io_restrict_auth--so the client is the only one directly exercising its
privilege--it would be insecure to have it generically obey the redirection
from the server.  In that case, the server couldn't abuse your privilege
generically to create other files or whatnot, but it could still abuse it
in subtle ways like causing you to write a file other than the one you
wanted written.  This is the same fundamental issue as symlinks owned by
joebob, which is exactly a case of the user-retries interface.  But
programs know about symlinks and can (and do) take explicit security
precautions before following what the filesystem told them to do.

It's obviously useful to have certain translator programs that root trusts
to behave "properly" even when set on a node owned by a random user.  You
can do this trivially by making /hurd/shadowfs setuid root.  What's
probably more desireable is to install root-owned /servers nodes for the
trusted translators, and have them all written to use fshelp_delegate.

> Hmmm.  Can you ever use shadowfs as a bootstrap filesystem for a new
> (sub) Hurd?

I've never thought about anything quite like that.  The basic sub-Hurd
concept is that `boot' gives you a virtual version of what real booting
gives you.  i.e., there is nothing to talk to but the kernel and devices.
If there were any way to talk to the underlying Hurd's filesystems, the
connection to it would be a new bootstrapping issue.  But now that you
mention it, this seems like a very useful feature!

I am imagining a scenario where you have a pristine system install image in
a directory on your main Hurd (e.g. from a bunch of "make install" from
your native development environment), and boot a sub-Hurd whose bootstrap
filesystem is a shadowfs reading from your install tree and writing to
another directory on your main Hurd.  In this kind of scenario, there is
still no real visibility between the two Hurds.  So I don't think you need
to worry about the auth servers and such.  The sub-Hurd's auth server is a
figment of some user's imagination in the view of the main Hurd.  The
sub-Hurd's bootstrap shadowfs is welcome to believe whatever it likes about
the uids of its users.  As far as the main Hurd's filesystems are
concerned, that shadowfs is just some task somewhere that has some
directory ports authenticated however they were authenticated (i.e. opened
by `boot' in the normal way), and it can subset that authorization with
io_restrict_auth if it wants to.  


There is an entirely different kind of "shadowfs as the bootstrap", that I
don't think you were referring to, but bears mention anyhow.  That is
having a bootstrap filesystem (ext2fs or whatever) that has shadowfs (or
anything else) set as the translator on its root node.  (Something like
this might eventually be the norm.)  I don't think this is handled well
right now.  But what it should probably do is get through the bootstrap as
if there were no translator on root, as far as getting init going.  Then
start up the translator in the normal way to get the translated root port,
and give that to init as the root port to start programs with.

> > That is, each virtual directory has a cached port if the underlying
> > directory has been created or an existing one used, and if there is no
> > cached port you get your dotdot's port and do the lookup and dir_mkdir as
> > necessary.
> 
> But with what name, the name it was looked up under?  I am worried about
> things like renaming middle-directories between the lookup and the mkdir
> call (worried in a confused way, because thinking about multiple filesystems
> and multiple users in a shdowfs way always makes me very dizzy).

Hmm, interesting question.  I think the first thing to figure out is what
behavior makes sense to a user for this kind of case.  When you have done
any writing so some COW has happened, and then the underlying directory has
renames, what should it mean?  We need to explore this more, but I have to go.