Re: Shadowfs - some notes

[Roland McGrath]

> there was a discussion about Shadowfs' write support on IRC (#hurd @
> openprojects.net) and Marcus suggested to post the conclusions - so
> here they are.

I think I disagree with all of your conclusions, but I'm very glad you've
been talking about the subject.  (I hope this means someone wants to go
implement it soon!)

> The first question was: If shadowfs supports having an explicitely
> specified writable filesystem[0], shadowfs might has to create whole
> directory hierarchies - how can this be done? (Or should it be done at
> all?.)

In a shadowfs that supports writing at all, this is most certainly the
behavior it should have.  Anything else just doesn't make sense as a user.
Incidentally, this is what BSD's "union" mount type does.

> Example: settrans /shadow /hurd/shadowfs --writable /a /b
> (which explicitely specifies /a as the only writable filesystem).

Just as an aside, might I suggest supporting relative pathnames taken
as starting at the underlying node, so:

        settrans /shadow /hurd/shadowfs --writable . /b

is the same as your example, but uses the directory underneath the
translator at /shadow in place of /a.  On BSD, this is done with:

        mount -t union -o -b /b /shadow

> 0) a filesystem shouldn't do such operations (like creating
>    directories), the user should. So there would be problems with the
>    new permissions.

Nope; that's what io_restrict_auth is for.  It's not entirely clear from
the name or the comment in io.defs, but when a directory port returned by
io_restrict_auth is used to create a node, that node's uid and gid are set
to the uids[0] and gids[0] parameters of the io_restrict_auth call.  So
really the way to think of io_restrict_auth is that it gives you a port
that the server treats as if it had done an auth transaction and gotten
your uids/gids parameter arrays as the results from the auth server.  So,
use io_restrict_auth to get a port to the writable underlying directory on
the user's behalf, and make dir_mkdir or file-creating dir_lookup calls on
that port.

> 1) it would mean that in every looked up virtual directory node in
>    shadowfs, the according path would have to be stored. This is not
>    nice. (An alternative to storing the path in every node would be to
>    automatically create the directories on the writable filesystem as
>    they are successfully looked up. Then the creation of whole
>    directory hierarchies wouldn't be needed.)

>From a little experimentation, creating all the directories on read-only
lookups seems to be what BSD does.  Seems a little iffy to me, but if it's
ok for them I guess it's not so bad.

But I don't think it would be a problem to instead keep the in-core virtual
directory nodes alive for the path taken to any externally live virtual
node.  I'm not entirely sure what your implementation plan would be without
doing that.  That is, virtual directory nodes keep a pointer to their
dotdot node.  When you need to create a file in an underlying directory,
you get a port to your dotdot's underlying directory and make the
appropriate dir_lookup call on that.  Getting a port to your dotdot's
underlying directory is a recursive process going back up to the root.
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.