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

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

hello andreas

thanks for the question, we have been paying attention to this issue recently, 
and here are our current thoughts.

first off, it's not just the owner and group information that is passed as a 
string. with the addition of RPCSEC_GSS mechanisms, it's also the transport 
rpc_cred princapal. for AUTH_UNIX, the rpc_cred princaipal was expressed as a 
uid. for AUTH_GSS, it's a per-mechanism name.

Kerberos v5 mechanism:   user@kerberos-realm 
      e.g:
[email-masked]

SPKM3 (PK based) mechanism:  Distinguished Name
e.g: 
C=US, ST=Michigan, L=Ann Arbor, O=University of Michigan, OU=TEST -- CITI 
Client CA v1, CN=andros

and future mechanisms can have different name formats.

second: the security mechanism needs to be taken into account in order to 
distinguish between similar names with different security contexts. an example 
of this:

AUTH_UNIX file owner [email-masked] - this is a unix name with a dns domain

vs

AUTH_GSS: file owner [email-masked] - this is a kerberos v5 name.

they may not be the same person.

third: at the University of Michigan, there are multiple kerberos realms, and 
students typically belong to at least 2 realms -

so [email-masked] = [email-masked] = [email-masked] = [email-masked]

futhermore, in a perfect world, one would like to give file system priv's to 
users in remote realms - such as permitting [email-masked] access to a file 
protected by umich.edu kerberos realm.

so, in our opinion, use of symbolic names in ACL's would not abolish the need 
for a central registry of mappings, and the local filesystems should continue 
to use numeric identifiers.

here is the kind of mapping that might exist for a single user on a single 
file:

uid = local user name = [email-masked] = [email-masked]... 
= DN = name@remote security realm  etc.

these mappings will be stored in a site-wide database. note that if needed, we 
can make each name a tuple, attaching the security mechanism (from the rpc 
transport) to the name to resolve conflicts.

where any one of the above names returns the uid which maps to a set of ACL's 
in the local file system.

our code currently makes an upcall to our GSSD daemon to resolve the name to a 
uid/gid  (and visa versa).  GSSD is also used for gss context creation. 
currently, GSSD resolves a name-uid by consluting /etc/passwd /etc/group - we 
simply open and read the files. this was a first pass design. the name<->
gid/uid mapping is stored in a kernel cache.

our current thoughts are to use the name service caching daemon by callning 
getpwnam(3), getpwuid(3), getgrnam(3), getgrgid(3) (which we should have done 
in the first place ;0 ), and then investigate any extensions to the NSCD 
needed to securely contact the central database where the multiple names to 
single numeric identifier mappings are held.

-->Andy Adamson

> Hello,
> 
> Stephen Tweedie has brought up an interesting issue concerning user/group
> symbolic names to identifier mapping a while ago, when discussing ways of
> integrating Access Control Lists into the kernel. Maybe you have an
> opinion on it.
> 
> On traditional filesystems like ext2/ext3, user/group identifiers are
> stored numerically, with conversions to/from symbolic names done by user
> space processes (lookup in /etc/passwd, etc.). The current Linux ACL
> implementation at <http://acl.bestbits.at/> also only supports numerical
> user/group identifiers as user/group qualifiers in ACL entries.
> 
> In contrast, NFSv4 ACL entries may contain arbitrary [email-masked] or
> [email-masked] entries. In the past, NFS has used mechanisms to map
> between numeric identifiers and symbolic names, and has used numerical
> IDs when communicating with the rest of the kernel. Using symbolic names
> in ACLs would abolish the need for a central registry of mappings, but
> they would also brings up several problems that currently cannot be
> handled by the kernel: Symbolic names are of arbitrary length, and thus
> are more difficult to handle. The file owner/owning group on filesystems
> like ext2/ext3 can only be numeric. The mapping between users/groups and
> identifiers may not be stable (e.g., consider a domain name change).
> Access decisions are currently based on numeric ID's; an ACL that
> contained symbolic names would have no valid interpretation in the context
> of the standard kernel (while it might make sense in the context of the
> NFS daemon).
> 
> What is the current position of the Linux NFSv4 project concerning these
> issues? Have there been any discussions about supporting symbolic
> identifiers on the server side, and how they would integrate with
> authorization in NFSv4? If symbolic names are not to be supported, are
> there any updated plans concerning the name/ID mapping?
> 
> 
> Many thanks,
> 
> Andreas Gruenbacher.
> 
> ------------------------------------------------------------------------
>  Andreas Gruenbacher, [email-masked]
>  Contact information: http://www.bestbits.at/~ag/
> 
> 
> 
>

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 16 May 2002 10:42:50 -0700

Jim Rees wrote: 
> 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.

I agree that those are distinct but the question is how best to deal
with that fact.  It seems to me that mapping those to separate numeric 
id's is not the desirable way.  I think it would be very difficult to 
set up ACL's (for example) that said that tried to properly distinguish
unix-rees from kerberos-rees from unix-andros from kerberos-andros.

I think you either trust auth-unix or you don't.  If you don't, then
either you just don't allow it, or you decide unix-rees == unix-andros
== nobody.

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

I suppose that, strictly speaking, that is true.  If the servers uid's
are the two's-complement of the client's then everything will work.
However, there are very significant constraints on the mappings to make 
sure that everything will work.  In particular, if the client maps 
two uid's to different strings, then if the server had better map them 
to different uid's that map back to those same strings.  In other words,
every user the client knows about, the server must know about also.
I think it would be harder to maintain separate user db's with everything 
in sync except the actual id's than to keep a single user db so that
everybody agrees.

The server could store the string rather than a numeric id and this
could work, except for the issue of interoperating with v2/v3, but I
don't think you will be able to ignore that issue for a very long time.

---

From: "wurzl, mario" <[email-masked]>
Date: Fri, 17 May 2002 16:20:08 -0400

From my understanding of the spec., although the server may use any internal
format for Owner and Owner_Group attributes, when exchanging these
attributes with the client (SETATTR or GETATTR), they should be in the form
user@dnsDomain UTF8 encoded.

Mario Würzl

-----Original Message-----
From: Noveck, Dave [mailto:[email-masked]]
Sent: Friday, May 17, 2002 14:47
To: [email-masked]'; [email-masked]
Cc: [email-masked]
Subject: RE: Mapping user/group ID's in ACLs

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: "Corbett, Peter" <[email-masked]>
Date: Mon, 20 May 2002 11:57:45 -0700

While GSS_API does provide APIs for mapping between mechanism specific internal and external name formats, it does not provide a solution to the general name mapping problem, as it provides no way to associate names from different mechanism's namespaces.  We also have to live with current KDC implementations, including Microsoft's, where there is little to no hope of mandating a format change.  As Spencer pointed out, we have to deal with mechanisms other than kerberos, which only adds other name formats to the mix, without providing any solution to the problem.  And GSS_API does not have, nor will it have, any recognition of NFS V4 names, since they are not mechanism names by definition.  So, I think we are left to solve this problem outside of GSS_API and in a mechanism independent way.  That leaves open the question of why V4 needs its own namespace.  I'm not sure why this is necessary; why, for example X.500 Distinguished Names would not have sufficed to identify NFS V4 !
users.  But, given the current state of affairs, some mapping service that is backed up by the variety of name services available in whatever environment we are running in (e.g. LDAP, NIS, /etc/passwd), is required.

Peter