Subject: RE: id's as strings in the spec

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 14 Jun 2002 14:29:52 -0700

> > > > 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'm not convinced that your approach with "12345" usernames works. 
> Consider what happens if the server and the client does not have the same 
> uid/username mapping: You read in a file from tape with uid 4711, which 
> does not exist on the client. The client contructs the username "4711" and 
> sends over the wire. The server stores the file with uid 4711. Then the 
> client does GETATTR. The server, which has a local user with uid 4711, now 
> returns "[email-masked]" instead of "4711". The local client does not 
> know anything about "[email-masked]", and cannot translate this back 
> to uid 4711.

The current approach requires that cleints and servers maintain agreement.
If they don't funny things will happen, such as in your example.  Howvere,
that is true whether we have the 4711 case or not.

> So, the idea of letting the server interpreting "4711" username strings 
> does not work if the client and the server does not have the same 
> uid/username mappings. And as far as I understand, v4 does not mandate 
> that they must. I thought the whole idea of string based usernames was to 
> eliminate the need for syncronizing uids between servers and clients. 

I don't think that is the idea or that string-based usernames achieves
it.  The existence of numeric id's is what generates the requirement
that machines agree on the assignment.  If a V4 server goes whole hog
and implements string-form usernames down to the on-disk-fs level and 
v2 and v3 and auth-sys go away (I can dream, can't I), then the server
doesn't have to have matching uid's since he doesn't have to have any
uid's.  But the clients, which if they are unix-based have API's that
involve numeirc uid's had better agree among themselves of users will
get very strange results.  If I map a given uid to one name and it is
read by a client that has no mapping for that name, results are going
to be strange.

> > 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.
>
> Really? Where can I find this in the spec?

You can't.  I infer it from the fact that Mike says that he expects that
most server's will store numeric id's and if they do that, they had
better agree or nothing will work.  So there has to be a mechanism and
the spec does not define it.

> After thinking about these issues, I (currently :-) believe that this is 
> the way to go:

> 1) The server SHOULD preserve the string in a SETATTR-GETATTR sequence
> (at least as long as the server uid/name mapping is not changed). I 
> believe that this is necessary to avoid all sorts of strange cases. 

That requirment avoids some strange cases, but I think the strangeness can
be limited to it is not harmful.  This may be because I take a different
view of what your approach would require of implementations, or rather
of the implications of that requirement.

> 2) How should the server handle a SETATTR for a "unknown" user? I think
> there are no "invalid users" from the v4 point of view. The server should
> accept ALL username strings, regardless of wether there is a local uid
> mapping or not. So, I think NFS4ERR_BADOWNER is a bad idea (yes, I've
> changed my mind...). The question is of course how servers that stores
> uids in the filesystem should deal with this. I suggest that they can use,
> for example, the method described by Marius
> (http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/2002/0209.html):  
> Files owned by "unknown" users can be stored under a special uid (like
> -2). The real username then has to be stored somewhere else, for example
> in an extended attribute (EA) or some other, local database.

> Of course, the implementation burden is a bit higher, but not impossible I 
> think.

It is not impossible, but this kind of requirement, especially at this late
date, would extend the development cycle for people who are now thinking
about when they might ship.  And I believe that the big challenge for
V4 is to get people using it.  I'm willing to tolerate some of the
occsional strangenesses in cases where client use unknown userid's and
then things change so the client and server don't agree on the user
mappings.  It's a tradeoff with  TTGSOH (time to get something out
there).  

> 3) Is it OK to have several usernames for the same uid in NFSv4? Sure,
> since the v4 spec does not talk about uids. But you must still ensure that
> a SETATTR-GETATTR sequence preserves the username. The easy way to ensure 
> this is not to have several users with the same uid, or several uids for 
> the same user. 

> In practice, UNIX-based servers can detect "wrong setups" by using 
> "reverse lookups", in a way similiar to what sshd does with domains & 
> IPs: 

> On all SETATTR("someuser") requests, the server can assert that
> getname(getuid("someuser")) == "someuser". If not, then you have two users
> with the same uid. The server logs and returns an error.

> On all GETATTR(someuid) requests, the server can assert that 
> getuid(getname(someuid)) == someuid. If not, you have several uids for the 
> same user. The server logs and returns an error.

> 4) What should the server do for a GETATTR on a file with a unknown uid?  
> Log and return an (server) error. This will only happen if the
> uid/username mapping is removed on the server.

What user was that so I can fix it.

I'm sorry, you're not allowed to have that information.

> 5) What about users from different domains? When the server recieves an
> userstring (like "[email-masked]"), it should first check if the domain
> part matches the servers local domain. If it does, the domain part is
> stripped off and the username ("joe") is used. If this username is
> unknown, or the domain-part didn't match, the user is treated as an
> "unknown" user. The username is stored in EAs or separate metadata
> database.

This sounds like a reasonable implementation for servers that want to
implement this but a terrible requirment.

6) Should a special "UID string form" username (like "4711") be included
in the v4 spec? Yes, but this form should not be interpreted by servers;
only by clients. Servers should treat these strange usernames just like
any other unknown username (that is, use EAs or metadata database). (Well,
of course, it's also possible to allocate uids for some of these strange
names. For example, a server can allocate uids 65535-131070 to usernames
"[email-masked]"-"[email-masked]", and use uids < 65535 for normal
usernames.)

Clients can translate from this special form to uids. 

I think this special form should also include the domain name, like
"[email-masked]". This will prevent collisions for clients in different
domains. There is still a chance of collisions if there are several
clients in the same domain that does not have syncronized uid/users
mapping, but I think we can live with that.

I have probably missed something, but to me, it looks like this scheme 
would solve most problems:

* Servers will always return the same username in GETATTR as was used in 
SETATTR

* Clients can store files with "unknown" uids, for example, when reading 
in files via tar from tape. 

The answers to Daves questions with this scheme would be:

>     Mapping that map lots of strings to the same id or restricting
>     the range of valid string by returning an error.

A third approach: All strings are valid. 

>     What to do about id's in the fs that don't map to any string.  
>     Numeric id escape or something else?  (what?)

When the server finds a file in it's local fs that don't map to any string
(on the server), return an error. When clients need to store files with 
uids that don't map to any string (on the client), the client can use the 
escape mechanism. 

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

I prefer "[email-masked]", but "4711" is also fine with me.  
"[email-masked]" will prevent using usernames beginning with #, but I
don't think that will upset many users.

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 14 Jun 2002 14:31:52 -0700

oops.  I just hit send when I meant to hit save.  This is an incomplete,
and unproofread response.  You'd be better off deleting this and waiting
for the real response later this evening.

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 14 Jun 2002 21:41:13 -0700

I wrote:
> and unproofread response.  

What I should have said was that it was not proofread.  Unproofreading 
something seems kind of perverse :-)

---

From: "Noveck, Dave" <[email-masked]>
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=[email-masked]"

(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 "[email-masked]".

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=[email-masked]"

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=[email-masked]"

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 [email-masked].  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.

---

From: "Corbett, Peter" <[email-masked]>
Date: Tue, 18 Jun 2002 11:48:41 -0700

I was talking to Dave about this yesterday, and espoused the following opinion to him, which he suggested I share with the group.  The names stored for V4 owner and owner group attributes should be drawn from a consistent name space.  There are two viable options here: names extracted from and X500 entry, or names cobbled together in an independent NFSV4 namespace.  In either case, mappings are required between the uid/gid space and the V4 namespace, as well as between the V4 namespace and other name spaces, such as kerberos V5.  The advantages of X500 names is that they conform to a well defined format (see http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-dn-07.txt), they are unique within the accessible scope of any computing environment, and they are served up by LDAP directory servers.  If that name form were to be specified in the spec, no further qualification of the name string would be needed.  The LDAP directory servers can also be adapted to serve up other na!
me representations of the user's name and uid/gids as part of their user schema.

Using an ad hoc V4 format for internal names requires less standardized infrastructure outside of V4.  However, it does allow the sort of ambiguities that arise when multiple security mechanisms, each with its own naming scheme, are used by the same user community.  Some care must be taken externally to avoid ambiguous translations from one namespace to another.  It is allowable to punt this outside of NFS, just as the GSS_API punted on the same issue when they were in a position to tackle it.  Specifying an internal NFS V4 naming convention passes the problem to implementers and administrators without giving them much guidance on how to solve it.

Both of these techniques are superior to allowing any name form native to a security mechanism to be used as the internal name in V4.  The problem there is that we then remove from the server any ability to unambiguously distinguish between the names of different users.  The server must have this ability.  Using X500 names accomplishes this inherently.  Defining a new name form specifically for NFSv4 and forcing all name forms to map into it forces that, but leaves the implementation of the mapping undefined.  It does not require an LDAP infrastructure.  Either of these can be made to work, and is preferable to allowing arbitrary mechanism specific name forms to be used as internal V4 names.  One way to allow arbitrary name forms would be if the name was concatenated with a namespace specifier, in the form of a security mechanism specifier (OID, sec flavor number, sec flavor short name, or the like).

Peter

---

From: [email-masked]
Date: Fri, 21 Jun 2002 13:45:39 -0500

Hello everyone,

I have finally caught up on this interesting thread of notes. As I get
though each note, I always come back to the conclusion that string based
owner names have the same issues as uid and gid in inconsistent registry
spaces. In fact, strings are worse because they raise compatibility issues
with existing data, file systems, applications, and os architectures. They
also present performance challenges and complication to NFS implementers.
Why not just add owner_uid and owner_gid into the optional file attributes?
Keep the names too. I realize there is the id conflict issue with ids
equating to different users in disjoint registry spaces. I don't see that
as a significant issue for several reasons. Customers understand this issue
well and know what to do to handle it. If they care about consistency and
security, they have already or will move to centralize user information or
synchronize registry spaces. The conflict issue becomes less important with
RPCSEC-GSS authentication. The client no longer dictates the credential
based on a uid mapping. Instead, the authentication context is derived from
an authentication service that the client and server both trust. Now
credentials are controlled by the server improving the integrity of object
ownership at creation time. The addition of uid and gid to the spec should
not impede the progress of implementations as its a fairly simple
adjustment. In fact it seems it would simplify things. The benefits are
application compatibility, NFS V2/V3 and local access compatibility, ease
of implementation, and performance.

For example, if an application does the following:

{
.
.
chown(path, 1000, 5000);
chmod(path, S_ISGUID |....);
stat(path,...)
...
}

It expects the stat to show 1000 and 5000 as the st_uid and st_gid. If the
affected object is an executable, it is expected to run under id 1000 on
execution. Customers are going to demand this level of compatibility.

The string names still have value. For example, they can be used as a
validation check on SETATTR(CHANGE_OWNER). An administrator could configure
a NFS server to perform an equivalency check between the uid and the string
name. Only if each reverse maps to the other, is the ownership change
allowed (assuming other privilege requirements are met). With this you put
the choice in the customer's hands.

As for owner strings, I think the RFC should be pretty specific about their
format and how they are constructed. The proposed user@dns_domain form, is
open to interpretation as this discussion has shown. I read it and
concluded "dns_domain" is the network domain of the machine's primary host
name (nfs1.austin.ibm.com yields dns_domain austin.ibm.com). I could draw
multiple conclusions about "user". I prefer to think of it as the short
descriptive name in the user registry referenced by the server or client.
For /etc/passwd, its the username, the principalName in NIS+, the memberUid
(not uidNumber) in RFC 2307, and so on. Certainly many of the forms
presented in this discussion are different than my interpretation.
Different interpretations mean different implementation semantics and
interoperability issues at the operational level even though there is RFC
compliance. That's wrong!!

It just seems like a practical move to put uid and gid in the protocol.
These concepts will be around for a very long time. There is a ton of data
in this format. It will increase by one or two magnitudes before things
might change. NFS V3 will be around for a long time. In fact it will
advance and increase in usage, as NFS V4 gets off the ground. Migration
must be as painless as possible.

Whenever I read in the RFC or follow the WG discussions, I reference the
following checklist:

o Does it provide compatibility with existing applications, data, and file
systems
I view this as critical.

o Can it perform as well or better than NFS V2/V3 - especially at scale
Again, its critical

o Does it simplify or complicate the admin model
Simplification is good!

o Can it be implemented without retooling the OS or underlying file systems
 I know its possible; I was part of a team that created a stateful secure
scalable distributed file system across 3 major versions if AIX, 4 versions
of Solaris, Windows NT, and OS/2 with no required OS changes.

Carl

Carl Burnett
AIX Kernel Architecture - Distributed File Systems
(512) 838-8498, TL 678-8498
(please reply to [email-masked])

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 21 Jun 2002 14:25:52 -0700

Id's as strings aren't my favorite part of spec but I think they are
workable.

> I have finally caught up on this interesting thread of notes. As I 
> get though each note, I always come back to the conclusion that string 
> based owner names have the same issues as uid and gid in inconsistent 
> registry spaces. 

Not necessarily.  That is, if the implementation stores what it stores
today (uid/gid) then yes, implementations have the same issues with
inconsistent registry spaces.

However, if the (server) implementation chooses to store the string, 
then it does need a consistent registry.  It just stores what it is 
asked to store.

So if the protocol defines the the id's as strings then it allows an
implementation which does have today's issues with inconsistent
registry spaces but enables one that does not.  I see that as a win.  

> In fact, strings are worse because they raise compatibility issues 
> with existing data, file systems, applications, and os architectures. 

I think there are answers to the compatibility issues that you raise.
Solving them was my intention in proposing that SETATTR of numeric
string be allowed.  I think this addresses your case below.  Let me
know of the specifics of the problems you see.

> They also present performance challenges and complication to NFS 
> implementers.

My feeling is that the performance issues can be addressed through
appropriate caching of the mappings.  There will be a tiny net loss 
but I don't see this as enough to get rid of the strings.

The complications for implementers are quite real.  I'm working through
them now :-(

> Why not just add owner_uid and owner_gid into the optional file
> attributes? Keep the names too. 

I just think this adds more complications and opportuities for 
non-interoperability.  Clients will tend to use one or the other of
two methods.  It isn't clear how they interact at the server.  

If the strings aren't good, then let's get rid of them and replace 
them with numeric id's.  We could then defer the issue of the strings
to V4.1.

> I realize there is the id conflict issue with ids equating to 
> different users in disjoint registry spaces. I don't see that 
> as a significant issue for several reasons. Customers understand 
> this issue well and know what to do to handle it. If they care 
> about consistency and security, they have already or will move 
> to centralize user information or synchronize registry spaces. 
> The conflict issue becomes less important with RPCSEC-GSS 
> authentication. ! The client no longer dictates the credential 
> based on a uid mapping. Instead, the authentication context is 
> derived from an authentication service that the client and server
> both trust. Now credentials are controlled by the server improving 
> the integrity of object ownership at creation time. The addition of 
> uid and gid to the spec should not impede the progress of implementations
> as its a fairly simple adjustment. In fact it seems it would simplify
> things. The benefits are application compatibility, NFS V2/V3 and 
> local access compatibility, ease of implementation, and performance.

I think the compatility issues can (and have been) addressed within
the context of the string id's.

As far as ease of implementation, I would agree what it would be simpler
if we replaced strings with uid/gid.  If they're just added, I think things 
get really complicated.

As far as performance, I think the effect is small, probably smaller
than the effect of the new attribute model, which makes you do,
at least conceptually, a test for each possible ayttrobute bit, rather
than straight-line code.  I'm not proposing getting rid of the new attribute model.  It has other benefits and the small performance challenges can be addressed in various ways.  Similarly for the id strings.

> It expects the stat to show 1000 and 5000 as the st_uid and st_gid. 
> If the affected object is an executable, it is expected to run under 
> id 1000 on execution. Customers are going to demand this level of
> compatibility.

I agree.  My intention is that this work, at least when the id
registries are the same on client and server.  I don't think we require
(with the proposed section 5.6) that 1000 and 5000 have assigned user
names.

> The string names still have value. For example, they can be used 
> as a validation check on SETATTR(CHANGE_OWNER). An administrator 
> could configure a NFS server to perform an equivalency check between
> the uid and the string name. Only if each reverse maps to the other, 
> is the ownership change allowed (assuming other privilege requirements
> are met). With this you put the choice in the customer's hands.

You are requiring that OWNER and OWNER_UID be set in tandem in the
same SETATTR.  But if you really require that then clients are going
to have to have the code to have the same mappings as the server, etc.

If you say that it is only required when the server administrator says
so, then you have a nightmare.  Clients will not do this and will wind
up failing.  So the choice is not really in the customer's hands,
if he needs to have certain clients working.

Strings or numeric id's are both possible answers but I think having
both would be a nightmare.

> As for owner strings, I think the RFC should be pretty specific 
> about their format and how they are constructed. The proposed
> user@dns_domain form, is open to interpretation as this discussion 
> has shown. I read it and concluded "dns_domain" is the network domain 
> of the machine's primary host name (nfs1.austin.ibm.com yields 
> dns_domain austin.ibm.com). I could draw multiple conclusions about
> "user". I prefer to think of it as the short descriptive name in the 
> user registry referenced by the server or client. For /etc/passwd, 
> its the username, the principalName in NIS+, the memberUid (not 
> uidNumber) in RFC 2307, and so on. Certainly many of the forms 
> Different interpretations mean different implementation semantics 
> and interoperability issues at the operational level even though 
> there is RFC compliance. That's wrong!!

Agreed.

However, if we keep the strings, and I think we will, that problem 
will exist.  Adding numeric uid/gid in addition will not solve it.

> These concepts will be around for a very long time. There is a ton of 
> data in this format. It will increase by one or two magnitudes before 
> things might change. NFS V3 will be around for a long time. In fact it
> will advance and increase in usage, as NFS V4 gets off the ground. 
> Migration must be as painless as possible.

I agree with the goal.  I just don't see that having two forms of 
identification at the same time will help achieve them.

> Whenever I read in the RFC or follow the WG discussions, I reference 
> the following checklist:

> o Does it provide compatibility with existing applications, data, and 
> file systems
> I view this as critical.

Agree.  I hope this has been addressed.

> o Can it perform as well or better than NFS V2/V3 - especially at scale

Performance depends on how you measure it.

V4 provides some performance benefits for many workloads.

The id strings can't improve performance and will hurt it a tiny bit.

Overall, V4 will perform better but for workloads that don't take 
advantage of V4 improvements or where the client and server do not
use the V4 features (e.g. delegations), there may be some loss.
I don't think it will be a visible loss.

> o Does it simplify or complicate the admin model

The administrative model is not being made more complicated.

The id strings will allow a simpler administrative model than is
possible with numeric id's.  No idea when that simplicity will be 
realized, however.

> o Can it be implemented without retooling the OS or underlying file 
> systems I know its possible; I was part of a team that created a 
> stateful secure scalable distributed file system across 3 major 
> versions if AIX, 4 versions of Solaris, Windows NT, and OS/2 with 
> no required OS changes.

I'm probably not the best judge of how this plays out for V4.  Because
ONTAP is not a user OS, it doesn't have the same constraints (which
is a good thing when we have to implement protocols like CIFS).  However, 
the one V4 feature that required major infrastructural change, the
V4 locking model with delegations, is certainly not one I would reject
on those grounds.  It was certainly worth the effort from my point of 
view.

The id mapping stuff required the developement of a general id mapping 
(and associated caching) facility usable throughout the system, but otherwise
didn't impact the system outside of the V4 code.