From: Spencer Shepler (shepler@eng.sun.com)
Date: 06/14/02-03:47:28 PM Z
Date: Fri, 14 Jun 2002 15:47:28 -0500 From: Spencer Shepler <shepler@eng.sun.com> Subject: Re: id's as strings in the spec Message-ID: <20020614204728.GI100497@dhcp-uaus08-128-189.sun.com> On Fri, William A.(Andy) Adamson wrote: > Dave wrote: > > Andy wrote: > > > if you don't allow mapping of several names to a single uid, how do you get > > > around the problem of different name formats for different rpcsec_gss > > > mechanisms? > > > > By saying that those name formats are not necessarily what you should > > pass as the OWNER and OWNER_GROUP attributes and SETATTR (and get back > > on GETATTR and appear in ACL's, etc). > > > > If you can map all those formats to a numeric uid, and I believe that > > in your environment you can, then you can also map it to the unix username > > that that uid corresponds to. > > right. but all you're asking is that i add more entries to the name<->name<-> > uid<->whatever mapping. i don't see any advantage. The mappings will be present anyway, right? The client and server would need to deal with normal local identification and that may or may not look like a security principal. It may be a regular unix user or windows user name. There is a mapping from security principal to uid and there is going to be a mapping from uid to "local" user name as well. Constructing the owner and owner_group should be taking the local name and appending the "domain" of the system. > > > x509 DN's, available as an SPKM3 name, and kerberos v5 names have different > > > formats, both can legally represent the same user (uid) and both security > > > mechanisms are supported buy rfc3010. > > > > Right, but just because those mechanisms are supported does not mean that > > the names that each uses internally to identify users may be used verbatim > > as the text of the OWNER attribute. > > correct. but, in the end, the OWNER attribute and the rpc credential principal > have to be mapped to one another. Certainly they have to map: principal <-> uid <-> owner > > a server which stores the > > strings sent, without having to impose these uid restrictions, would > > not work. You would have different owners for the same user coming > > in on different security mechanisms, > > but, this is my point: you already have different owners for the same user > coming in on different security mechanisms. when an OPEN request comes over > the wire, how do you determine the identity of the requestor to see if the > requestor has access to the file ? from the rpc transport. you have to take > the princpal name (or for AUTH_UNIX, the uid) and map it to a local filesystem > owner representation, and then ask the filesystem. > > even better: take a SETATTR request to change the OWNER attribute of a file. > before its allowed, the rpc principal has to be mapped into the local > filesystem owner representation before the request is processed. in a similar > fashion, the OWNER name in the request will be mapped to a local owner > representation. all of this mapping occurs on both client and server. > > i don't understand why you think the OWNER attribute used in GETATTR and > SETATTR differ from the owner of the rpc request. If a mapping occurs (the local filesystem is not storing the RPC principal) and it should, then what we get is a general name that allows for some flexibility as these environments move forward. NFSv4 is defined in a way that allows for future growth by the additional use of varying security mechanisms. > > so would have to have equivalence > > classes of owners that were really the same owner, but the differences > > between the elements of those classes would have no signficance for > > anybody. > > right - as of now there is no difference. this is an argument for associating > a security flavor (and thus pseudoflavors) with and ACL entry. then, different > rpc cred principal names along with the flavor could be stored, and different > access to a file could be given depending on the strength of the rpc transport > security on a per file basis. This can still be done but the underlying identifier needs to be such that the server would allow for the varying security mechanisms and future growth. If the server wants to employ additional interpretation of a principal's access capabilities based on what security mechanism being used, it can certainly do that but the protocol should not bear the responsibility of that directly. > this argues that you store something that identifies the > > equivalence class, > > of course. whether you store a unix name or a uid or whatever, you are storing > an equivalence class due to the required mapping of differing rpc transport > pricipals. > > > i.e. the real user. > > a uid is everybit as much as a real user as a unix name. consider an NFSv4 > file server that exports a filesystem with your unix names instead of uid's. > futhermore, the filesystem is only exported with the spkm mechanism. add the > fact that no access through the local filesystem is allowed (an administrative > decision). > all users identify themselves to the exported filesytem with a DN. what is > the advantage to local unix name vrs a uid? is the local unix name a real > user? no. only spkm names are 'real users' because only they can access the > filesystem. True. However, is the client's handling of those owners ready to deal with spkm names? Obviously it will handle the spkm names as part of the RPC credentials but is that functionality available to the NFS application that may be written on top of the RPC functionality? > > The originator of this part of the spec, Mike Eisler, says this was his > > intention. That's not dispositive but I give it considerable weight, > > especially since he agrees with me :-) > > > > The alternative forces clients to have knowledge they should be required > > to have. > > Suppose I mount using SPKM3 and store a file and it now gets > > an SPKM3-style OWNER attribute. > > right. it's an spkm owner because it's an spkm rpc transport, and the > credentials that give access to the file have that name format. note that > whether the server stores 'unix names' or uid's as an internal representation > of the file owner, the incoming NFSv4 request uses the rpc transport name as > the owner of the request, and thus the server has to map the spkm name to a > local filesystem owner (be it a uid or unix name) As mentioned above, what does the client have to do? It has some work to do in all of this as well. > > Now later I or someone else on a > > different client mounts using kerberos. This client may not even support > > SPKM3, but it would get an SPKM3-style OWNER and have to decode it to > > turn it into a uid. > > no. if the server is exporting the filesystem with both spkm3 and kerberos > security mechanisms, it will have to map between spkm and kerberos names and > local file system owner names in order to determine file access from rpc > transport cred names. so, it simply returns the name that matches the > rpctransport format as the OWNER. It could do that and it could also map to a potentially more general name that would allow for flexibility at the client. > >That's just wrong. > > i agree that returning an spkm OWNER name for a request secured by kerberos is > wrong. > > i also think it's wrong to return a unix OWNER name from a request secured by > non-unix secuity. So maybe we need to briefly revisit the purpose of owner and owner_group in the context of interoperability. The obvious reason that the content of owner and owner_group is loosely defined is that standards around mapping a name like that to identification in Unix, Windows, and other environments are not in common/consistent use. So the definition is flexible to allow implementations to adapt as those mapping mechanisms become more common. APIs also need to adapt as Dave has mentioned. The problem I see with tieing the owner/owner_group name exactly to the security principal is that this makes the assumption that the RPC functionality for dealing with those identifiers are readily available to the NFSv4 portion of the implementation. This may be true for some environments but is not true for others. Having the level of indirection of user@domain for owner/owner_group allows for flexibility. Spencer
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:52 AM Z CST