From: William A.(Andy) Adamson (andros@citi.umich.edu)
Date: 06/14/02-01:55:58 PM Z
Subject: Re: id's as strings in the spec Date: Fri, 14 Jun 2002 14:55:58 -0400 From: "William A.(Andy) Adamson" <andros@citi.umich.edu> Message-Id: <20020614185558.27E66207C7@citi.umich.edu> 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. > I think that's the intention in the spec > even though it is certainly not explicit. > i never read it that way. > > 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. > I say this for a number of reasons: > > If that were the case, then the simple server implementation implied > by this (and maybe the ultimate goal here), uhhhh, in my humble opinion, there is no such thing as a simple NFSv4 server implementation! ;0 > 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. > 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. > So 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. > > 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) > 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. >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. -->Andy > Cc: 'Peter Åstrand'; nfsv4-wg@sunroof.eng.sun.com; andros@citi.umich.edu > Subject: Re: id's as strings in the spec > > > > Peter Astrand wrote: > > > On Mon, 10 Jun 2002, Noveck, Dave wrote: > > > > > > However, we realize that in real life, most servers will > > > > store traditional numeric id's for a number of good reasons > > > > (e.g. supporting auth_sys and interacting with v2/v3). As > > > > a result, when you SETATTR OWNER and GETATTR it back, you > > > > may not get back the value you set. > > > > > > It would be nice to always get back what you stored. > > > > Yes it would. > > > > > > I think there are some aspects of this non-invertability that > > > > aren't particularly troublesome. If it happens that there > > > > are a few names that map to the same numeric id, because they > > > > are truly synonyms then a SETATTR-GETATTR sequence is going > > > > to change things, unlike for more normal attributes. There's > > > > not much to do about this but note that it can happen. > > > > > > I'm probably a bit naive right know, but what about not > > > allowing/recommending several names to map to the same numeric id? It's > > > not recommended to have several users with the same uid on UNIX systems > > > either, at least most people consider this a bad idea. > > > > I agree it's a bad idea. > > i disagree. > > 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? > 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. > > > The question is how far we can mandate > > goodness, while keeping the implementation burden for v4 within > > bounds. If we tell the server that he needs to guarantee that two > > username will never have the same map to the same uid (even when > > the administrator changes a uid for some reason), means that what > > he has to implement for himself is very significant as oppposed to > > making NIS calls and getting something that most of the time has > > the desirable propertied, but without guarantees. > > > > In practical terms, the only way that the server can guarantee > > that the id you store will be the one you get back, is to stote > > the string in the local fs, which may not be possible, and if > > possible, may not be desirable (interaction with v2/v3, etc.). > > > > > > The troublesome case is the large number of strings that > > > > have no numeric id. In fact, almost all of the more than > > > > 128**(2**32) possible strings, have no such numric id. Under > > > > normal circumstances, the client will be able to avoid presenting > > > > any like this, but not always. So what is the server to do? > > > ... > > > > I think in these cases, we want an error. The spec should > > > > define a NFS4ERR_BADOWNER error for non-recognized strings. > > > > Then at least, if there's a setup problem, it can be called > > > > to people's attention, and fixed. > > > > > > I agree. > sounds reasonable. of course, the server in most cases would not have a user > associated with all possible uid/gid either, so this same error could also be > returned for non-recognized numbers. > > > > > > > Now let's consider the complementary problem. It may also be > > > > the case that GETATTR (or READDIR) encounters a numeric id > > > > for which there is currently no string defined. This may be > > > > the result of deleted users or simply the fact that v2/v3 and > > > > local file systems allow you to set owner and group to any > > > > numeric value. An error here would be highly undesirable. One > > > > thing to do is to map these to nobody. The problem is that > > > > this makes the semantics of a directory to local disk different > > > > from v2/v3. One might copy a file, even to local disk, and > > > > as a result change the ownership of files with obsolete or > > > > other not-currently-set-up users. > > > > > You are thinking about the case when root are copying files around, for > > > example, and ownership is normally preserved? > > > > > The ownership is at least preserved from the v4 point of view, if you use > > > an anonymous user. > > > > Right but the v4 point of view is not the same as the point of > > view of client OS. > > > > > >I, at least, would find > > > > this annoying as a user. > > > > > > OTOH, this should only happen if your setup is wrong. > > > > I have a set of users. My setup is fine. > > i have a set of users each with multiple names mapped to single uids. my setup > is fine. > > > > > I read in a tar tape that happens to have uid's that I don't have > > in my /etc/passwd. My setup has not become wrong. > > > > If I make a change to something and generate the tar tape, on local > > disk or v2 or v3, the only change to the tape will be the change > > I made. I'd like v4 when used on systems like unix/linux that > > have this traditional behavior, not to interfere with it, even though > > in retrospect, we might decide that exporting numeric id's in that > > fashion was not particularly good choice. > > > > > >One way that this could be dealt with, > > > > with the spec as it stands, is for the server to return something > > > > like 12345@your-domain but that is not guaranteed to avoid conflict, > > > > since the user 12345 (with numeric id 54321 perhaps) might exist. > > > > You could do something like 12345@gimme-those-old-time-numeric- > > > > ids.tm (after making a suitable payment to the government of > > > > Turkmenistan), but I'd like to propose that the spec define a > > > > more standard escape for this type of situation, something like > > > > 12345@#. > > > > > > Another idea is #12345. > > > > > > Further they may accept @# id's (for a SETATTR) if there > > > > is no other string form id which maps to the same local > > > > filesystem owner. They may (SHOULD?) restrict this to > > > > users with appropriate priviliges, and give others > > > > NFS4ERR_BADOWNER. They MUST reject (with NFS4ERR_BADOWNER) > > > > @# id's if there is another string form id which maps to > > > > that same local filesystem owner. > > > > > It seems to me that the client may have a hard time knowing if there is > > > another string form for the owner and what that me be. > > > > If client cannot take a numeric id and determine what the matching > > username is, then the whole approach of owners as strings cannot > > work. It's based on the idea that through some unspecified mechanism > > the client and the server can maintain agreement on the valid set > > of usernames. > > > > > Your proposal also > > > means that owner-strings like 12345@# can become invalid to use for a > > > client all of a sudden, if a string-form of that user is created on the > > > server. > > > > I don't see that as a problem. I only use such strings when I can't > > map a numeric id to a string. When I can map such an id, I will be able > > to send the appropriate string and should stop sending the numeric form. > > > > > I haven't thought about these issues much, but my general feeling is that > > > either we should allow the use of the 12345@#-strings all the time or not > > > at all. Not at all would be preferred, since the concept of UIDs does not > > > belong in the v4 spec. > > > > Yes but the reality exists. v2 and v3 are out there and had that concept > > and a lot of stuff has been built up assuming it, such as many local file > > systems that will exist for a long time. > > > > > > > > Mapping that map lots of strings to the same id or restricting > > > > the range of valid string by returning an error. > > > > > I prefer recommending/enforcing an one-to-one mapping. > > > > a one to one mapping won't work given the multiple per file security flavors. > > > > Recommending is one thing but how do you enforce it? > > > > > > What to do about id's in the fs that don't map to any string. > > > > Numeric id escape or something else? (what?) > > > > > > I prefer an anonymous user string (preferably specified by the spec), but > > > this is probably just because I haven't understood your explainations why > > > this is a bad idea :-) > > > > You've expressed the reason just above. You'd like one-to-one mappings but > > mapping lots of stuff to a single anonymous user is a very-many-to-one > > mapping. > > > > > > > > > > > > > > > >
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:51 AM Z CST