Subject: id's as strings in the spec

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 10 Jun 2002 11:26:56 -0700

I'm considering how to resolve the issues for the spec 
raised by the representation of users and groups as 
strings (rather than just whining about them as I had 
been doing).

It appears to me that it is clear how this would work
for servers that choose to store the actual string for
the user and group.  OWNER and OWNER_GROUP are just 
ordinary unproblematic attributes, the client doesn't 
really need any special knowledge about what the server
is doing (except maybe a fairly easily specified mapping
between pricipal and user), and everything just works.
In particular, when you SETATTR OWNER to something and
GETATTR back OWNER, you get back what you stored, under 
pretty much all circumstances.

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.  This makes OWNER
and OWNER_GROUP "funny" attributes in these circumstances
and the spec doesn't really discuss how to deal with this
fact.

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 [email-masked] and it is
mapped to [email-masked], then it winds up being owned 
equally by [email-masked] and [email-masked], since 
both of those also map to [email-masked] (and also to any
other anonymous users).  This might be a problem.  Similarly 
with SETATTR'ing an ACL entry that allows access by 
[email-masked].  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.

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.

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)
@# 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. 
 
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?)

     If special escapes, what are rules on when thay may be used?

---

From: Peter Åstrand <[email-masked]>
Date: Mon, 10 Jun 2002 22:32:16 +0200 (CEST)

On Mon, 10 Jun 2002, Noveck, Dave wrote:

> may not get back the value you set.  

It would be nice to always get back what you stored.

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

> any like this, but not always.  So what is the server to do?
...
> to people's attention, and fixed.

I agree. 

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

>I, at least, would find 
> this annoying as a user.  

OTOH, this should only happen if your setup is wrong. 

>One way that this could be dealt with,
> 12345@#.  

Another idea is #12345. 

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

>      the range of valid string by returning an error.

I prefer recommending/enforcing an one-to-one mapping. 

>      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 :-)

Thanks for bringing up these issues Dave, they are important. 

-- 
Peter Åstrand                Telephone: +46-13-21 46 00
Cendio Systems               E-mail: [email-masked]
Teknikringen 3
583 30 Linköping
Sweden

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 11 Jun 2002 17:45:01 -0500

On Mon, Noveck, Dave wrote:
...
> 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.

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

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

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

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

-- 
Spencer