Re: ShadowFS (status)

[Steven Barker]

On Mon, Aug 27, 2001 at 03:47:21PM +0200, Marcus Brinkmann wrote:

> This is the right thing to do.  There is only one problem:
> If shadowfs has not the permissions to enter directories, it can not shadow
> them.  There is no secure way around it (if it could shadow them, it has
> the permission, which means it needs to be trusted not to give the dirs to
> users without that permission).  Should shadowfs shadow directories for which
> the caller has no permission?  Should shadowfs return retry names to
> unshadowed directory ports if it hasn't the permission to enter them?
> Should it do this if there is only one directory anyway?  Should it do this
> if there are more directories?

Hearing talk about shadowfs has inspired me do delurk after many months
reading the Hurd lists.  ShadowFS is one of the most "cool" things I see
planned for the Hurd.  I put some thought on how shadowfs *should* work
from the user's perspective, ignoreing the possible implemetation problems 
(like the translator's permissions).  If you can make the shadowing
"transparent" to the user, by making most operations work as expected, it
will be incredibly powerful.

A shadowfs has layers, of one filesystem on top of another.  It's role is to
give the user access to files in the proper layer.  Trying to read a file in
shadowfs should give access to the file in the highest level that exists and
is readable by the user.  It fails only when there is no readable version of
the file.  Writing should take place in the layer that is lowest, but not
under any layer with a readable version of the file.  This might require
copying an unwritable file into a higher layer, where it is writable.
Writing fails if there is no writable layer above the file.

Example:  
/foo is a simple shadowfs made up of /top on top of /bottom.
/top contains the file bar.
/bottom contains the file baz.

When I read or write /foo/bar, it works just as if I operate on /top/bar 
(ie, if I have enough permissions on /top and on /top/bar, it will succeed).

When I read /foo/baz, it works just like reading /bottom/baz.  Writing to
/foo/baz works too, if I have write permission.  If I do not, but I
have write permission in the directory /top then /bottom/baz gets copied to
/top/baz and I write to it there (the copy could be skipped if the file is
going to be truncated).  If I can't write either place, I get a permission
denied error.

If I try to create a file mumble, it should go into /bottom, if I can write
there.  If not, it goes into /top.  If I can't write in /top, I get an
error.

Deleting files is tricky (*ugly hack alert*).  If I delete /foo/bar, it
should act as expected, easily.  But if I try to delete /foo/baz, if I don't
have permissions to delete /bottom/baz, but I can write to /top, shadowfs
should write something to /top/ (maybe .baz.deleted?) that tells it that I
can't access /foo/baz any more.  If I can't create that file, I get a
permission denied error.

Now if all this behavior can work, you can do some really cool things with
it.  For instance, make /usrname be a shadowfs of /home/username on top of /
If you don't like /username/bin/someprogram you can delete it, or write your
own version over it.  The new copy will actually be in /home/username/bin,
rather than in /bin but that won't be obvious.

There are probably some subtle problems with all of this, like dealing with
translators in the shadowed filesystems, and with suid bits and such...
I hope those can be worked arround.  Shadowfs will be really amazing when it
lives up to it's potential.

-- 
Steven Barker                                      scbarker@uiuc.edu
  No one can guarantee the actions of another.
                -- Spock, "Day of the Dove", stardate unknown
GnuPG public key: http://www.students.uiuc.edu/~scbarker/pubkey.asc
Fingerprint: 272A 3EC8 52CE F22B F745  775E 5292 F743 EBD5 936B