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

From: Jim Rees <[email-masked]>
Date: Thu, 16 May 2002 11:04:29 -0400

I have two observations.  One is that I don't think Andy's proposed mapping
of multiple names to a single uid is correct.  "auth-unix/rees" and
"auth-kerberos/[email-masked]" may be the same person, but they should not
be treated as the same principal for access control purposes.  In the first
case, the server only requires the client's promise that I am who I say I
am, but in the second case the server should demand some kind of
cryptographic proof.

My second observation is that I don't think the mapping needs to be
universal site-wide, as Dave claims, except for interoperability with v2/v3.
In all other cases, the client can use one mapping, and the server can use a
different mapping, and everything will still work, because uids never
traverse the wire.

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Thu, 16 May 2002 11:20:57 -0400

> be treated as the same principal for access control purposes. 

that's up to the administrator. for example, the NFSv4 server could only 
export the file as under kerberos, but local access is allowed. in this case, 
the mapping i proposed makes sense.

> In the first

---

From: marius aamodt eriksen <[email-masked]>
Date: Thu, 16 May 2002 12:37:27 -0400

> the mapping i proposed makes sense.

which also raises the issue of users of the nfsv4 server that don't have
a uid on the server machine.  i believe we were discussing generating
uid's on the fly.  one could also have some sort of reserved uid
scheme, i.e. auth-kerberos/[email-masked] doesn't have a local uid on
the fileserver, but a file that he owns will have a special nfsv4 uid,
and auth-kerberos/[email-masked] can be stored in an extended attribute
known to the nfsv4 server.  though recalling extended attributes from
the local file system is (most likely) slower than reading a 32 bit uid,
i wouldn't think this would cause a performance problem.

marius.

-- 
> [email-masked] > http://www.citi.umich.edu/u/marius

---

From: Mike Eisler <[email-masked]>
Date: Thu, 16 May 2002 18:59:33 -0700

> a uid on the server machine.  i believe we were discussing generating

What does it mean for a user to not have a uid on the server? You
probably mean, that the server's mapping table, has no
mapping from auth-kerberos/[email-masked] to "bob" (or bob's
integer uid if the server's local filesystem stores integer
uids and not string uids).

> known to the nfsv4 server.  though recalling extended attributes from

That's one implementation approach. Others are to simply
deny access to auth-kerberos/[email-masked] or map
that principal to an anonymous uid. This is what
some NFSv[23] servers do today when they cannot map
an AUTH_DH, AUTH_KERB4, or RPCSEC_GSS principal name to
a native uid.

> i wouldn't think this would cause a performance problem.

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.

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.