Subject: RE: Mapping user/group ID's in ACLs

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 17 May 2002 13:52:27 -0700

So if "bob" is a user and "auth-kerberos/bob" is not
(presumably because a user cannot have a slash in it?), 
then the spec answers all my questions below in a way 
that I'm happy with.

The problem for me is Mike's statement that storing 
"auth-kerberos/[email-masked]" as the owner is a "valid"
implementation.  Since Mike wrote the spec sections in
question I'm paying particular attention to his interpretation.
So was Mike merely saying that the server is free to 
prepend anything (e.g. Lincoln's Gettysburg Address)
to the actual OWNER attribute on disk as long as it
strips it off before returning the value?  And that 
it would give an error on a SETATTR of OWNER specifying 
"Four score ... @umich.edu".  

Or was he saying that storing "auth-kerberos/[email-masked]"
was valid is some other sense, in which case things seem
a lot more complicated.

-----Original Message-----
From: wurzl, mario [mailto:[email-masked]]
Sent: Friday, May 17, 2002 4:20 PM
To: 'Noveck, Dave'; [email-masked]'; [email-masked]
Cc: [email-masked]
Subject: RE: Mapping user/group ID's in ACLs

>From my understanding of the spec., although the server may use any internal
format for Owner and Owner_Group attributes, when exchanging these
attributes with the client (SETATTR or GETATTR), they should be in the form
user@dnsDomain UTF8 encoded.

Mario Würzl

-----Original Message-----
From: Noveck, Dave [mailto:[email-masked]]
Sent: Friday, May 17, 2002 14:47
To: [email-masked]'; [email-masked]
Cc: [email-masked]
Subject: RE: Mapping user/group ID's in ACLs

Mike Eisler wrote: 
> Storing security flavor specific principals as the uid is certainly
> a valid implementation approach, but if there's any chance that
> the filesystem will be exported to accept different or
> additional security flavors, one would have to deal with that.
> If one is willing to store auth-kerberos/[email-masked] in
> the metadata, then why not simply use NFSv4 external
> uid strings, like [email-masked]? Then, for the common
> case, a trivial mapping/matching between auth-kerberos/[email-masked]
> and [email-masked] is achived. Better set, if the server's
> default NFSv4 uid domain is set to "umich.edu", then the server
> need only store "bob". That way, if the NFS server's domain
> changes, running a find command on the whole filesystem
> is not necessary. Use something like 
> [email-masked] to deal with the case when
> a "foreign" principal needs to be mapped on the server.

Besides the issue of what the server stores internally, there
is the corresponding issue of what is accepted by the server
for certain attributes and sent back by the server when those
attributes are accepted.

If the server stores either "bob" or "[email-masked]" in the 
filesystem, then presumably he is going to return "[email-masked]"
when OWNER is GETATTR'd.  That seems OK.

But if the server is going to store "auth-kerberos/[email-masked]",
then what he is he going to to return for the GETATTR?  If it is
"auth-kerberos/[email-masked]" (i.e. if that is a valid thing for
him to return), then the client is going to have to be prepared
to treat that the same as "[email-masked]" or at least do something
intelligent with it (i.e. not treat it as anonymous).  On the
other hand if he returns "[email-masked]" then GETATTR of OWNER
and a corresponding SETATTR (e.g. backup and restore) is going to 
change the OWNER attribute.  That doesn't seem right.

Similar issues apply when SETATTR'ing OWNER, OWNER_GROUP and 
ACL.  Should the server accept "auth-kerberos/[email-masked]"
or should the client strip "auth-kerberos/" first, or both.

My concern is that is that we could be creating lots of oppportunities
for clients and servers to be very creative in coming up with
subtle ways to mis-interoperate.  All of the mappings that we 
are talking about are trivial but the problem is that they 
don't appear in the spec and it is unclear who is to do what.
This makes it very easy for clients and server to obey the
spec and still not be able to usefully inter-operate, at least
as far as real users are concerned.   

> In this way, mapping tables can be sparse, administration
> simpler, and there's still a strategy for dealing with
> foreign principals which was the goal the global NFSv4 uid
> space.

---

From: Mike Eisler <[email-masked]>
Date: Sun, 19 May 2002 08:20:01 -0700

> "Four score ... @umich.edu".

It is probable that most implementations will store integers in
their server's file system. Even clean sheet NAS
servers will probably do so, so as to optimize
the use of AUTH_SYS (will we ever eradicate
AUTH_SYS in our time?). So, since it is recognized that
one method of non [email-masked] storage is a valid implementation,
then one has to recognized that it is valid to store anything. As long
as the implementation maps it to a consistent [email-masked]
on the wire. 
> was valid is some other sense, in which case things seem

I did note that storing auth-kerberos/[email-masked]
is valid, but it opens a mess of problems as soon as
you let RPCs with non-kerberos security flavors
get access.

Mario's understanding is what I intended.