On Sat, Jul 24, 1999 at 11:48:54PM +0100, Nix wrote:
> 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.

I wouldn't be so sure. Try exporting AFS using either samba or nfs, and
you're in for a surprise, they use the euid. And I don't really think
that the people who developed that were incompetent. Actually Linux
seems to be the only OS that has a fsuid, so it's not surprising that
AFS with its BSD background does not use it, although it is a very small
change ("sed 's/euid/fsuid/'" on the kernel code) to support it correctly.

> > 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?

Yes, any requests passed up from the kernel is `tagged' with a coda_cred
structure (containing the fsuid). The worker thread that handles the
request then grabs an authenticated connection for that user, or build a
new one using that user's coda-token. If there is no token available, an
unauthenticated connection is used. The server doesn't see fsuid's at
all, just authenticated and unauthenticated connections.

> 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.

Yes, the concept of untrusted clients and trusted servers is central in
the security model used by AFS, Kerberos, and Coda. Even if a client
workstation is compromised, the damage will be contained to only the
files that client has access to, and only for the period that the token
is valid.

> > > 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.)

It might actually work, but I'm waiting for the knfsd to reach stability
before trying it out. There are still enough Coda-related bugs to hunt down.

> > Well, the authentication system currently isn't even separated enough to
> > allow for sharing volumes between administrative cells.
> >                                                         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*...

I was looking at X509 certificates. If we have a known root certificate
that is known to all Coda clients, it can be used to sign cell/domain
certificates, which are then used to sign user certificates. If a token
consist of the cell + user certificates, Venus can verify that user_at_cell
is valid without the need for contacting the servers.

> 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...)

I don't know how much influence IBM had on the design and implementation
of AFS and Coda. But I agree that it is a fairly complicated system. And
every new feature, such as cells, has the potential of adding even more
complexity.

Jan