From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 06/13/02-04:10:17 PM Z
Message-ID: <8C610D86AF6CD4119C9800B0D0499E336A8E85@red.nane.netapp.com> From: "Noveck, Dave" <Dave.Noveck@netapp.com> Subject: RE: id's as strings in the spec Date: Thu, 13 Jun 2002 14:10:17 -0700 Spencer wrote: > On Mon, Noveck, Dave wrote: > ... > > > > 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. > > > > 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? > > > > One solution that has been discussed is to map them all to > > anonymous user (e.g. nobody@your-domain). I think this is > > fine for the mapping of principals that that come from, for > > example, Kerberos. An anonymous user will be able to do a > > limited set of things, may wind up complaining and the problem > > will be addressed somehow, outside of the NFS-v4 spec. > > > > But there's another situation which is very different. If > > someone does a SETATTR OWNER to dnovak@random.org and it is > > mapped to nobody@random.org, then it winds up being owned > > equally by schepler@random.org and iceler@random.org, since > > both of those also map to nobody@random.org (and also to any > > other anonymous users). This might be a problem. Similarly > > with SETATTR'ing an ACL entry that allows access by > > dnovak@random.org. Having this allow access by all anonymous > > users is not what you want 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. > > In the case of SETATTR of owner or owner_group, I agree that the > server should error off to let the client know that no mapping was > available. In the case of changing ownership, the server shouldn't > just pick some "other" value. I understand the first sentence in the paragraph above but the second seems to contradict it. How is "the case of changing ownership" different from a SETATTR of owner? > > 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. I, at least, would find > > this annoying as a user. 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@#. This will give you a way to express any numeric id > > that happens to appear in the filesystem when it can't be > > otherwise mapped to a string. > > Since the current spec does not define semantics for owner/owner_group > strings that do not have "@" as part of the string, "12345" may be a > sufficient return value for this case. I like this idea. It is guaranteed not to conflict with more standard owners. > > Of course there would then be the complementary issue about > > what to do about 12345@# on the other side, when you SETATTR > > it as an OWNER. One problem would be that this might leave > > open a hole whereby clients and servers could essentially > > avoid the whole id's-as-strings thing forever, simply imple- > > menting numeric id's, albeit in a slightly less performant > > way. Of course, they can do this now, if they agree, by > > defining a special domain whose user are simply the approriate > > numbers but 12345@# would make it more likely. > > > > Anyway, I would propose that servers may return @# id's if > > there is no other way to encode the user identification > > present in the local filesystem but MUST not otherwise. > > 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) > For the issue of what privileges must be in place to change "owner" or > "owner_group", the specification should use the "SHOULD" in this case > since the security issues are large with respect to changing ownership > of filesystme objects. This should be no different whether there is > or is not a mapping for "owner" and probably points to general > language needed for the SETATTR implementation section. I agree as long as we don't try to define in detail what those priviliges are (except where ACL's are directly involved). The issue of what special privileges to give special users such as auth-sys uid-0 or corresponding kerberos principals is up to the server implementation. > > @# id's if there is another string form id which maps to > > that same local filesystem owner. My idea here is > > that fs's (and the associated user API's) are very far > > from being truly ready for estendible general string-form > > user's and and V4 needs to accommodate those facts until > > the world is ready for something more general. > > If we allow/encourage the use of the string form of uid, how > do we encourage the development of mapping that is useful and > usable. I don't have an answer to this in that I believe > that we should be careful not to degrade functionality but > we do need to move forward. The way to move forward is not by defining better mapping, but by making the mapping irrelevant. At some point (it's far off, I know), fs's will provide string-form owners and groups internally. They will do this when v4-based protocols become ubiquitous and v2/v3 are truly legacy. At that point, the user mapping is the identity mapping. When we get the implementations out there, we will start a (very slow) process by which the old numeric id's will become obsolescent and finally obsolete. > > I'd like to try to come to a consensus about what to do > > about these (and any other related) issues so that I can > > draft appropriate changes for the spec. I'm hoping that > > we can focus on things that are doable now, rather than things > > that might have been doable six months ago or will be doable > > later a minor version. > > > > Specifically, we need decide what the spec says about issues > > that will arise with servers whose local fs's store numeric user > > id's. > > > > Mapping that map lots of strings to the same id or restricting > > the range of valid string by returning an error. > > > > What to do about id's in the fs that don't map to any string. > > Numeric id escape or something else? (what?) > The server should map to the numeric id. > > If special escapes, what are rules on when thay may be used? > No escapes. Just map to "12345" since that space is not defined > currently. > Also need to define what the user "nobody" is going to be since that > is the traditional mapping for the user "root" when it does operations > against an NFS server that is remapping its identifiers. I would > propose that it just be "nobody" without domain to signify the special > value. I like it, despite the fact that nobody@nowhere would be more poetic. :-) -- Spencer
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:51 AM Z CST