Subject: uid strings, was (Re: Draft minutes for Oslo NFSv4 WG meeting.)

From: Mike Eisler <[email-masked]>
Date: Wed, 11 Aug 1999 17:32:00 -0700 (PDT)

> Date: Thu, 29 Jul 1999 10:53:30 -0500
> From: "Spencer Shepler" <[email-masked]>
> Subject: Draft minutes for Oslo NFSv4 WG meeting.
> To: [email-masked]
...

> Mike [Eisler] then proceeded with various straw polls:
> 
>        Is the nfs v2/v3 32 bit uid/gid model broken in that it
>        
>                 is uncontrolled?
>                         8 Yes
>                         0 No
>          
>                         (Note that uncontrolled and "not collision
>                         proof" were defined as equivalent to avoid
>                         balkanization of the poll based on subtle
>                         semantic differences.)
>        
>                 allows too few identifiers?
>                         1 Yes

>         If so should we use
> 
>                 strings of form user@dns_domain?
>                         5 Yes
> 
>                 UUIDs?  1 Yes
> 
>                 something else?
>                         6 Yes
> 
>                 two or more of the above?
>                         0 Yes
> 
>                 all of the above?
>                         0 Yes
> 

I didn't see any reaction on the WG alias to the above two straw polls.

Clearly in Oslo, there was a plurality of support for using uids and gids of
form user@dns_domain, unless those opting for "something else" had something
in common in mind.

I note that Carl Beame's ACL proposal assumes "user@dns_domain" as the format
of id strings, and so far there's been no negative reaction.

Thus I interpret a consensus for the NFS V4 protocol using strings of form 
user@dns_domain format to represent user and group identifiers. If you
disagree, please speak up, and please accompany such disagreement with
a counter proposal.

	-mre

---

From: Carl Beame <[email-masked]>
Date: 12 Aug 1999 11:53:55 +0100

> of id strings, and so far there's been no negative reaction.

Actually my proposal was not JUST "user@dns_domain", but it also
included a flag indicating if the "id string" was a globally
translatable string or a local string. This is VERY important!!!

Maybe the id should be of the form:

	"user@dns_domain" for Globally translatable strings and 
	"xxxx@LOCAL" or "::xxxx" or "*xxxx" or (anything - xxxx) to
        signify that the xxxx is not translatable by the
        authentication scheme used. 

- Carl

---

From: Mike Eisler <[email-masked]>
Date: Thu, 12 Aug 1999 10:01:16 -0700 (PDT)

> translatable string or a local string. This is VERY important!!!

OK, but why is it important?

Is it because your are concerned about operating in environments where
the user doesn't have is own domain name?

In any case ...

>         authentication scheme used. 

just having "xxxx" with no @ symbol could efficiently convey the fact
that these aren't globally translatable. I think the nfs specification
should state that local names are discouraged since they lead to
problems once the organizations decides to connet to other organizations.

	-mre

---

From: Carl Beame <[email-masked]>
Date: 12 Aug 1999 19:58:37 +0100

> the user doesn't have is own domain name?
No.

Using a security mechanism like Kerberos sysadmins need to create
translation tables between local accounts and a global domain style
account "user@dns_domain". This translation is used by the server to
convert local ids (uids, sids) to a global name to pass over NFS.

Under NT and Unix you can create a file which is owned by or has ACLs
which refer to ids which are not in this translation table. The server
needs to pass this information to the client. It can't just tack on
the domain, since this may clash with another mapped account.

> problems once the organizations decides to connet to other
I agree, but we can't assume they will ever happen.

- Carl

---

From: Mike Eisler <[email-masked]>
Date: Thu, 12 Aug 1999 12:24:52 -0700 (PDT)

> convert local ids (uids, sids) to a global name to pass over NFS.

BTW, Ram Marti's message in 
	http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/1500.html
explains why a security mechanism's principal names are orthogonal to the NFS

> the domain, since this may clash with another mapped account.

So, what you want is a way for the serever to at least convey some kind of
identify in the event the sys admin has failed to update the
translation table. This is reasonable. 

> I agree, but we can't assume they will ever happen.

Agreed. Unless anyone objects, I'll assume we've reached consensus that
that uid and gids are expressed as a canonical form of:

	 user@dns_domain or group@dns_domain

In the event a server or client cannot translate from its operating system
user or group id, the server and client MAY use a string that has no @ symbol
to dennote names that are meaningful only to the client or server.

	-mre