Re: aname_to_locaname vs gssapi svc/host.domain.org@REALM

> >> Of course, this has _nothing to do with Kerberos_.  It's just applying
> >> IP-address-based access control, with all of the weaknesses that's
> >> always had.  If the owner of box2 uses whatnot/box2's tickets but spoofs
> >> box3's IP address, he will be able to access whatnot/box3's files.
> >
> > Under NFS4 as well?  Note the principal names (the one's I've been villified
> > for here) in my world identify the box and the user, and n4 doesn't put
> > uid:gid on the wire.

Those things are both true.  However, the NFS server must eventually map
the principal name onto a uid:gid to be used locally.  Once you map
multiple principals onto the same uid:gid, there is no going back -- the
information about the identity of the client host is gone.

That said, the approach you're using, of restricting different parts of
the filesystem to different clients with effectively disjoint UID
namespaces, can be a workable one.  It's not terribly scalable, and it
gets annoying when you want to share files between several clients, but
it's certainly no worse than what you had before Kerberos.  In fact,
it's almost exactly the same: in either case, you're trusting a client's
assertion about what host it is, in the form of the source IP address it
puts in its packets.

The only difference is that you're no longer trusting the client's
assertion about what UID it is; instead, you're requiring it to use
Kerberos to prove that.

Of course, there's nothing to say an NFS server implementation couldn't
have an ACL indicating which Kerberos principals are allowed to access
which exported filesystems.  With some pattern matching, you could even
do things like allow */box2.example.com to mount the filesystems
intended for box2.  I wouldn't recommend that, though, because it
amounts to inferring authorization solely from the existence of a
Kerberos principal, which is usually a bad idea.

Unfortunately, I don't believe current NFS server implementations
actually provide that capability.  That's a limitation of the NFS
server, though, not of Kerberos or GSS-API.

-- Jeff