From: Mike Eisler (mike@eisler.com)
Date: 05/16/02-08:59:33 PM Z
Message-ID: <3CE46405.8DAA8F61@eisler.com> Date: Thu, 16 May 2002 18:59:33 -0700 From: Mike Eisler <mike@eisler.com> Subject: Re: Mapping user/group ID's in ACLs marius aamodt eriksen wrote: > > * William A.(Andy) Adamson <andros@umich.edu> [020516 11:21]: > > > > 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/rees@umich.edu" may be the same person, but they should not > > > 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. > > 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 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/bob@umich.edu to "bob" (or bob's integer uid if the server's local filesystem stores integer uids and not string uids). > uid's on the fly. one could also have some sort of reserved uid > scheme, i.e. auth-kerberos/bob@umich.edu doesn't have a local uid on > the fileserver, but a file that he owns will have a special nfsv4 uid, > and auth-kerberos/bob@umich.edu can be stored in an extended attribute > known to the nfsv4 server. though recalling extended attributes from That's one implementation approach. Others are to simply deny access to auth-kerberos/bob@umich.edu 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. > the local file system is (most likely) slower than reading a 32 bit 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/bob@umich.edu in the metadata, then why not simply use NFSv4 external uid strings, like bob@umich.edu? Then, for the common case, a trivial mapping/matching between auth-kerberos/bob@umich.edu and bob@umich.edu 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 steve@msu.edu 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. > marius. > > -- > > marius@umich.edu > http://www.citi.umich.edu/u/marius
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:44 AM Z CST