Subject: owner string id study cases

From: [email-masked]
Date: Mon, 8 Jul 2002 11:05:55 -0500

Dave,

In light of the recent rework of section 5.6 in the RFC, I was hoping
that you might be able to go through the cases I have listed below and
define the expected behavior in each case. If you could explain what
the client would send, the resulting uids, and the server
response, that would be great.  I know this would be helpful to me for
understanding how to deal with string owner processing.  If nothing
else, this would seem to be a good test case scenario for vendors to
verify their implementations work as expected. Ideally, for a given
configuration all implementations would be capable of behaving the same.

I have based the cases on a simplified version of my earlier posted chown/stat
example. For any cases where the stat() would not yield an st_uid of 1000,
can you discuss how a vendor would explain this to a customer given it
would always work with NFS V3/V2?

Thanks,
Carl

The code example is:
{
....
chown(path, 1000, -1);
stat(path,...)
...
}

Assume the application has privilege to do the chown. Also assume
underlying file system stores numeric uid/gid.

=====

Assumptions about composition of NFS V4 string names. Let me know if these
assumptions are incorrect.

name form: user@dns_domain

user:
  user's short name (username) in a user registry (/etc/passwd, LDAP 2307,
  NIS, etc). Note: registry is assumed to be different from the
  authentication service's registry (a KDC). One could image a scheme where
  there was a combined registry that represented both authentication
  principals and credentials (DCE, Windows 2K), but I don't assume that here.

dns_domain:
  the DNS domain from the system's hostname. For example, the
  dns_domain for server1.sun.com would be sun.com.

=======

Cases:

Case 1:
------
Client and server in same DNS domain.
Both point to same user registry that has a user entry (carl) corresponding
to uid 1000.

Case 2:
-------
Client and server in same DNS domain.
Both point to same user registry. The registry does NOT have a user entry
corresponding to uid 1000.

Case 3:
-------
Client and server in same DNS domain.
Both point to different user registries. The client's registry has
a user entry (carl) for uid 1000. The server's user registry does
not have an entry for carl (carl@dns_domain).

Case 4:
-------
Client and server in same DNS domain.
Both point to different user registries. The client's user registry does
NOT have an entry for uid 1000. The server's registry has a user entry
(carl) for uid 1000.

Case 5:
-------
Client and server in same DNS domain.
Both point to different user registries. The client's user registry has a
user entry (carl) for uid 1000. The server has a user entry for carl with a
uid of 5000. The server also has a user entry for uid 1000, but
the corresponding name is dave.

Case 6:
-------
Client and server in different DNS domains (client.ibm.com, server.sun.com).
Both point to same user registry. The registry has a user entry for carl with
uid 1000.

==================================================

Some additional questions

Error handling question
---------------------------------
For the case where the server returns NFS4ERR_BADOWNER to a client,
what POSIX errno would you expect the client to return to the calling
application; EACCES, EINVAL, or something else?

dns_domain question
------------------------------
What happens if the system has a hostname without a domain portion.
Does this imply that maybe dns_domain in the owner strings is not tied
to the system's hostname, but to something different? What would that be?
Is it just an administrative parameter established at NFS configuration?

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: Mon, 8 Jul 2002 12:27:54 -0700

> dns_domain for server1.sun.com would be sun.com. 

Typically so, but I think that you have to allow clients and servers
configuration options.  For example, if the host were server1.eng.sun.com,
you might wnat the dns_domain to be either eng.sun.com, or sun.com, 
depending on what the scope of userid assignment was.

Making this configurable would also be necessary to deal with your
case 6 below.

> Both point to same user registry that has a user entry (carl) corresponding

Client translates uid 1000 and sends SETATTR specifying carl@domain, client
translates that to uid 1000.  On the GETATTR, server translate 1000 to 
carl@domain.  Client receives that and translates it to uid 1000.

> corresponding to uid 1000.

Client translates uid 1000 and fails.  Cleint may (allowed by the spec)
return an error at this point but probably will send send SETATTR specifying 
the string "1000".  Server is allowed by the spec to rejects this with a
BADOWNER error.  However it is most likely that after checking that there is
no translation for 1000 he just stores that (i.e. 1000) as the uid.  On the
GETATTR, server tries to translate 1000 and fails.  The server then sends "1000" as the owner.  The client receives that and translates it stores 1000 in st_uid.

> not have an entry for carl (carl@dns_domain).

Client sends carl@domain.  Server receives it and finds no translation
for it.  He returns BADOWNER.

Explanation for customer would be something like "Because of what appears
to be a configuration problem, the server was unable to determine what 
user corresponded to uid 1000.  Rather than do something that might be 
incorrect, which could have unfortuante security implications, the server
has refused the ownership change.  This operation would work in NFS-v2/v3
because they are designed for more limited environments in which all
userid's are under local control, thus making it unnecessary for the 
client and the server to agree on the meaning of individual id's."

> NOT have an entry for uid 1000. The server's registry has a user entry

Client translation fails.  Normally he will send server the string "1000".
Server will get the owner "1000" and note that it has a translation and
so will return BADOWNER (and he is free to reject the 1000 unconditionally).

Customer explanation similar to above.

> the corresponding name is dave.

The client will send carl@domain.  The server will store a uid of 5000.
On the getattr, the server will translate and return an owner calue
of carl@domain.  The client will translate this to the uid 1000.

> Both point to same user registry. The registry has a user entry for carl with

There are two cases.  Either you have configured client and server to have 
matching owner domains (which makes sense if you have the same user registry),
or you haven't.  If these are configured to be the same, then this winds up
to be case 1.

In the other case, the client would send [email-masked] and the server would
look at the ibm.com and return BADOWNER.

Another configuration possibility is that the server could be configured to
accept some set of guest id's from another domain, which seems a bit more
likely than getting ibm and sun agreeing on a common user registry :-)

> Some additional questions

It seems like EINVAL makes most sense.

> dns_domain question

I think it is an administrative parameter and that the most sensible value
is one which identifies the dns domain or sub-domain whose user registry
is being shared by the client and server.

That assumes that client and server will generate and accept only a single
value of domain in owners.  Another case is a server which will accept any
value (it doens't store numeric userids).  Another possiblity is a server
which will accept some discrete set of domains (and use a corresponding set
of user registries), storing a small domain index together with the uid or
gid.