Subject: RE: Mapping user/group ID's in ACLs

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 17 May 2002 11:47:04 -0700

Mike Eisler wrote: 
> Storing security flavor specific principals as the uid is certainly
> a valid implementation approach, but if there's any chance that
> the filesystem will be exported to accept different or
> additional security flavors, one would have to deal with that.
> If one is willing to store auth-kerberos/[email-masked] in
> the metadata, then why not simply use NFSv4 external
> uid strings, like [email-masked]? Then, for the common
> case, a trivial mapping/matching between auth-kerberos/[email-masked]
> and [email-masked] is achived. Better set, if the server's
> default NFSv4 uid domain is set to "umich.edu", then the server
> need only store "bob". That way, if the NFS server's domain
> changes, running a find command on the whole filesystem
> is not necessary. Use something like 
> [email-masked] to deal with the case when
> a "foreign" principal needs to be mapped on the server.

Besides the issue of what the server stores internally, there
is the corresponding issue of what is accepted by the server
for certain attributes and sent back by the server when those
attributes are accepted.

If the server stores either "bob" or "[email-masked]" in the 
filesystem, then presumably he is going to return "[email-masked]"
when OWNER is GETATTR'd.  That seems OK.

But if the server is going to store "auth-kerberos/[email-masked]",
then what he is he going to to return for the GETATTR?  If it is
"auth-kerberos/[email-masked]" (i.e. if that is a valid thing for
him to return), then the client is going to have to be prepared
to treat that the same as "[email-masked]" or at least do something
intelligent with it (i.e. not treat it as anonymous).  On the
other hand if he returns "[email-masked]" then GETATTR of OWNER
and a corresponding SETATTR (e.g. backup and restore) is going to 
change the OWNER attribute.  That doesn't seem right.

Similar issues apply when SETATTR'ing OWNER, OWNER_GROUP and 
ACL.  Should the server accept "auth-kerberos/[email-masked]"
or should the client strip "auth-kerberos/" first, or both.

My concern is that is that we could be creating lots of oppportunities
for clients and servers to be very creative in coming up with
subtle ways to mis-interoperate.  All of the mappings that we 
are talking about are trivial but the problem is that they 
don't appear in the spec and it is unclear who is to do what.
This makes it very easy for clients and server to obey the
spec and still not be able to usefully inter-operate, at least
as far as real users are concerned.   

> In this way, mapping tables can be sparse, administration
> simpler, and there's still a strategy for dealing with
> foreign principals which was the goal the global NFSv4 uid
> space.

---

From: Mike Eisler <[email-masked]>
Date: Sun, 19 May 2002 08:08:06 -0700

> change the OWNER attribute.  That doesn't seem right.
...
> as far as real users are concerned.

Agreed. My intent was that on the getattr/setattr would
use "[email-masked]", as noted in section 5.6 of rfc 3010.
I'd never considered that one might morph "user@dns_domain" to
"mech/user@dns_domain". It's yet another thing to be
clarified in the next NFSv4 RFC. The clarification should
be that GETATTR should always return the same string regardless
of security mechanism or any else peripheral to
the operation (e.g. don't return one value for
client A, and another for client B).

	-mre