From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 06/18/02-10:52:21 AM Z
Message-ID: <8C610D86AF6CD4119C9800B0D0499E336A8EA2@red.nane.netapp.com> From: "Noveck, Dave" <Dave.Noveck@netapp.com> Subject: RE: id's as strings in the spec Date: Tue, 18 Jun 2002 08:52:21 -0700 Andy wrote > > 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. > > right. the mappings will be avaliable anyway. so, why not allow the attribute > owner /owner group name to be mapped at the server into the rpc cred > principal name so that the client doesn't have to? I don't understand this statement. If the client does a GETATTR of OWNER, why would the client need to map the name received into the rpc cred pincipal name? On unix systems it is going to map it into a numeric uid to be returned by stat. On what kind of client would it need to map it something like "C=US, ST=Michigan, L=Ann Arbor, O=University of Michigan, OU=TEST -- CITI Client CA v1, CN=andros@citi.umich.edu" (or something of yet a different form based on the security flavor that is being used to access the NFS server)? Even if such clients exist, they are not going to be the majority. Why ask the server to do such a mapping? > > > > 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. > well, i say that this 'general name' only has meaning if it can be mapped to > an rpc credential name, which is the name that is used for file access. so, > this 'general name' is nothing more than additional mapping to the rpc cred > name, which i guess is ok.... I don't don't want to get into a big philosophical discussion of the meaning of "meaning" but I guess I will anyway: Suppose you are accessing a server using SPKM3 using GSSRPC with NFS-v3. You do a GETATTR on a file and the uid field in the response is 4711. Does that have meaning even if there is no such user set up to use SPKM-3 and thus no mapping to a principal? Or is this a case of "That's not meaning. It's just bits."? Your client returns that value to the caller of stat. Does st_uid have meaning or is it just bits? The program doing the stat (suppose it is ls), does a getuser call and /etc/passwd is consulted and value "nominalist" is returned. Does that have menaing or is it just a string? The user looks at the ls ourput, and he thinks he seems something at least borderline meaningful. Is he wrong? Now repeat the experiment after doing v4 mount. The GETATTR returns "nominalist@nfsv4.org". The client does the the equivalent of a getuid (with some caching thrown in). He returns 4711 as the st_uid field. ls maps it back to "nominalist" and prints that. The user looks at the same ls output. Meaning, who needs it? > > > > > > 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. > the protocol should comment on it's dependency to map the attribute owner and > owner_group names to the rpc credential names. without this mapping, NFSv4 > won't work. Where is it required to map owner_group names to rpc credential names? These various security mechanisms have their own formats for principal (=owner) names, but do they have special name formats for groups? As far as the owner goes, the mapping that I see as necessary is from rpc credential names to owner. I don't see where the inverse would be required. Since multiple rpc credential names (from different security flavors) can map to the same owner, the inverse map isn't well-defined. A given owner has a (non-signleton) set of rpc credential names corresponding to it, which means that you have to restrict the map in some way (according to the security flavor of the issuer, or the one who created the file, or ...) > > > 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? > 3010 says the owner name should be of the form 'name@realm'. what is wrong > with this name@realm? > "C=US, ST=Michigan, L=Ann Arbor, O=University of Michigan, OU=TEST -- CITI > Client CA v1, CN=andros@citi.umich.edu" Nothing. So is <Insert text of War and Peace here>@tolstoy.org, but my server won't know what to do with it, or rather it will know precisely what to do with it, return NFS4ERR_BADOWNER, which I think is definitely the right thing to do. It will do the same with your name above, which you think is not right, I suppose. A server that stored arbitrary strings would accept both, which might be the wrong decision in the first case. Ooh! What a great QA test. Doing a SETATTR OWNER_GROUP such that the disk space to store the string causes you to go over quota. Add lots of client threads doing stuff like this for extra credit. This whole thing points up the problem not with your name above but with 3010. It says very little about names and you and I read it and we each come up with a clear interpretation of what it obviously must mean. Unfortunately, we don't have the same interpretation. > > > > > > 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. > > the client has to understand any 'name@realm' presented to it, and to me, > "understand' means, map the name to a local filesystem identifier. > > > > > > 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. So where is that in the spec? You'd think that if that was the idea, that little detail would be mentioned, somewhere. To get back to your name, "C=US, ST=Michigan, L=Ann Arbor, O=University of Michigan, OU=TEST -- CITI Client CA v1, CN=andros@citi.umich.edu" If the is a valid name@dns_domain, and I suppose it is, then why is it not valid to return it in the response to a GETATTR of OWNER to someone using kerberos or auth-sys? And if it isn't valid, why would we be forcing the code in NFS-v4 server to interpret the strings it gets back differently based on the security flavor the rpc layer is using to acess the server. That looks like terrible layering to me. And what form, is it supposed to return if the GETATTR if from auth-sys? > > > > 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. > a name has no meaning without context in a security realm. no meaning. i don't > care how flexible you are. if you give me (i'm an nfsv4 client/server) a name > that i can't map into the rpc cred transport security name space of a security > realm under which the file was exported, i don't know who you are talking > about! Suppose I don't trust all these security mechanisms enough to export root access via any of these mechanisms. Root access is only available via the local file systems to those physically present in the electromag- netically shielded machine room with armed guards, retinal scanners, etc. Now, if you do a GETATTR using nfs-v4 and the file is owned by uid 0, then you are going to return something like root@paranoia.org. I suppose you could put it enough C='s etc to make it look like an SPKM3 name but it wouldn't really be one. In any case, the result wouldn't be valid because root is not available by spkm3 or kerberos or anything but local access. So maybe you don't know who is being talked about, but ls can still print root, and you know the set of people it could be. > > > > 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. > well, someone has to deal with these identifiers. i don't see this name > translation to be the job of the rpc layer. Not clear exactly what name translation "this name translation" refers to. > the rpc layer performs the > necessary identity checks using negotiated keys etc and then simply presents > the credential along with the name to the application. Works for me. > it doesnt give a whit > about what the application does with the name, as well it shouldnt. OK. > so if not > the rpc layer, and not the NFSv4 portion of the implementation, then where is > this magic supposed to take place? How did we get here? Why is the mapping of the results of GETATTR-OWNER to a local file system id not to be done in NFS-v4 client code? That is the only place I could imagine it being done, and I believe that is Spencer's assumption as well. Do you think it would be done somewhere else? I believe Spencer's point is that if it is done in the NFS-v4 code, then it may be difficult for the NFS-v4 code to get access to the functionality to map that security-mechanism-specific names to local fs id's since that code is part of the rpc layer. I agree with that and further say that even if you can do that, the result is so ugly that it should indicate to you that you've layered things wrong and that you should not put that burden on the NFS-v4 client code. It should, to the degree possible, not care what security mechanism it is using, or perhaps I should say, what security mechanism is being used on its behalf. > > 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. > > > i'm not suggesting that 3010 requires the attribute names to exactly match the > rpc credential names. i am suggesting that the only names that have meaning > are those that can be mapped into the rpc cred security namespace, and that > perhaps 3010 should acknowledge that fact. If it is a fact. > i am also disagreeing with the idea > of requiring only one valid name format for the attribute owner and owner > group names. if i have an NFSv4 client/server that wants to only deal in rpc > cred names for the owner/ ownergoup names, this should be allowed. Whatever happened to inter-operability? If you want to say, that it your client's right to to do SETATTR OWNER specifying a "C=..." name, and it is my server's right to return NFS4ERR_BADOWNER when you do that, then fine, but it doesn't suggest that we are going to inter-operate very well, at least as real users would define that. I'm sure that your server will accept what your client does, but the point of all that we are doing is to ensure that your client and my server, or Dan's client and your server, for example, can interoperate.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:53 AM Z CST