Jan Harkes writes:
> On Sat, Jul 24, 1999 at 02:30:39PM +0100, Nix wrote:
[snip]
> > Nice idea, but unfortunately the Linux nfsd does, er, evil tricks, like
> > using setfsuid() to transform itself into other users, and so forth.
> 
> That is not a problem, because Coda already uses the fsuid to determine
> which user is accessing the filesystem. We needed that for exporting
> /coda with, for instance, Samba.

Good :) it occurred to me shortly after sending it that unless you were
all incompetent (which does not seem to be the case) you'd be using the
fsuid anyway.

> > Effectively, the nfsd will need the ability to become any user at any
> > time, and will need to hold all tokens :( or so it seems to me.
> 
> A nfs-client user needs some way of obtaining a token for his uid on the
> nfs-server/coda-client.

I think I'm getting this token stuff at last. Am I right that the coda
client has a mapping from fsuids to (tokens,coda-uids) on every client?

If so I can see why the tokens are needed; otherwise there's nothing
stopping the lovely NFS-system attack of spoofing uids owned by other
people on clients.

>                         They are kept around by the coda-client. So the
> nfs daemon doesn't need to know about it.

(which makes sense, as the authentication is the job of the client, not
of nfsd!)

> > Am I missing something? Is there a way to do this? Is anyone doing it?
> 
> I did it with the userspace nfsd,

That's what I'm using, good. (I don't know what would happen if you
threw the knfsd at coda, or any virtual filesystem, but I doubt it would
be pretty.)

>                                   the only funny thing was that at first
> it didn't want to export any network-filesystem. However if you add the
> --re-export flag to nfsd it will be able to export filesystems like /coda.

This makes sense, it's not (directly) associated with a device.

[snip]
> Well, the authentication system currently isn't even separated enough to
> allow for sharing volumes between administrative cells.

Is this the reason for the current one-cell-per-client limit?

>                                                         For that we need
> to add at least uid mappings, and a way of validating authentication
> tokens that have been generated in a different domain.

The first is easy enough (although unless done carefully it opens up
some of those nice NFS uid-spoofing attacks, albeit only at clog time);
the second bit will probably be quite nasty :( even with the space of
valid tokens sparse, merely proving that this token could be valid won't 
prove that it *is*...

>                                           But as soon as you scale up
> to a distributed network with multiple administrative authorities is
> doesn't work that well anymore.

Agreed. Luckily there is only one administrative authority here (me);
but if more come in I can see why a kerberos/coda token scheme becomes
useful.

One thing's true; you can detect the Hand of IBM in this code; IBM tend
to make everything they do horribly complicated, and that is definitely
true here :) (mind you, the same thing is true of reiserfs, and that's
*not* connected with IBM...)

-- 
`When one finds oneself with an NxN coding complexity issue, it usually
 indicates the need for adding a layer of abstraction.' --- Hans Reiser