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

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 14 Jun 2002 08:45:34 -0700

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.  I think that's the intention in the spec
even though it is certainly not explicit.

> 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.  I say this for a number of reasons:

     If that were the case, then the simple server implementation implied
     by this (and maybe the ultimate goal here), 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, 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.  So this argues that you store something that identifies the
     equivalence class, i.e. the real user. 

     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.  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.  That's just wrong. 

-----Original Message-----
From: William A.(Andy) Adamson [mailto:[email-masked]]
Sent: Thursday, June 13, 2002 5:44 PM
To: Noveck, Dave
Cc: 'Peter Åstrand'; [email-masked]; [email-masked]
Subject: Re: id's as strings in the spec 

> Peter Astrand wrote: 
> > On Mon, 10 Jun 2002, Noveck, Dave wrote:
> 
> > > 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.  
> >
> > It would be nice to always get back what you stored.
> 
> Yes it would.
> 
> > > 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.
> > 
> > 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. 
> 
> I agree it's a bad idea.  

i disagree.

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

> The question is how far we can mandate
> goodness, while keeping the implementation burden for v4 within
> bounds.  If we tell the server that he needs to guarantee that two
> username will never have the same map to the same uid (even when
> the administrator changes a uid for some reason), means that what
> he has to implement for himself is very significant as oppposed to
> making NIS calls and getting something that most of the time has
> the desirable propertied, but without guarantees.
> 
> In practical terms, the only way that the server can guarantee
> that the id you store will be the one you get back, is to stote
> the string in the local fs, which may not be possible, and if 
> possible, may not be desirable (interaction with v2/v3, etc.).
>
> > > 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?
> > ...
> > > 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.
> >
> > I agree. 
sounds reasonable. of course, the server in most cases would not have a user
associated with all possible uid/gid either, so this same error could also be 
returned for non-recognized numbers.

> 
> > > 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.  
> 
> > 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.
> 
> Right but the v4 point of view is not the same as the point of
> view of client OS. 
> 
> > >I, at least, would find 
> > > this annoying as a user.  
> > 
> > OTOH, this should only happen if your setup is wrong.
> 
> I have a set of users.  My setup is fine.

i have a set of users each with multiple names mapped to single uids. my setup 
is fine.

> 
> I read in a tar tape that happens to have uid's that I don't have
> in my /etc/passwd.  My setup has not become wrong.
> 
> If I make a change to something and generate the tar tape, on local
> disk or v2 or v3, the only change to the tape will be the change
> I made.  I'd like v4 when used on systems like unix/linux that
> have this traditional behavior, not to interfere with it, even though
> in retrospect, we might decide that exporting numeric id's in that
> fashion was not particularly good choice.
> 
> > >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@#.  
> > 
> > Another idea is #12345. 
> 
> > > 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.  
> 
> > 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. 
> 
> 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.
> 
> > 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 don't see that as a problem.  I only use such strings when I can't
> map a numeric id to a string.  When I can map such an id, I will be able
> to send the appropriate string and should stop sending the numeric form.
> 
> > 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.
> 
> Yes but the reality exists.  v2 and v3 are out there and had that concept
> and a lot of stuff has been built up assuming it, such as many local file
> systems that will exist for a long time.
> 
> 
> > >      Mapping that map lots of strings to the same id or restricting
> > >      the range of valid string by returning an error.
> 
> > I prefer recommending/enforcing an one-to-one mapping. 
> 

a one to one mapping won't work given the multiple per file security flavors.

> Recommending is one thing but how do you enforce it?
> 
> > >      What to do about id's in the fs that don't map to any string.  
> > >      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 :-)
> 
> You've expressed the reason just above.  You'd like one-to-one mappings but
> mapping lots of stuff to a single anonymous user is a very-many-to-one
> mapping.
> 
> 
>  
>  
> 
>  
>

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Fri, 14 Jun 2002 14:55:58 -0400

Dave wrote:
> 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.

> I think that's the intention in the spec

i never read it that way.

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

>  I say this for a number of reasons:
> 
>      by this (and maybe the ultimate goal here), 

uhhhh, in my humble opinion, there is no such thing as a simple NFSv4 server 
implementation! ;0

> a server which stores the
>      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.

> so would have to have equivalence
>      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.

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

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

>  Now later I or someone else on a
>      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.

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

-->Andy

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 14 Jun 2002 15:17:13 -0500

> even though it is certainly not explicit.

Generally, yes.  The server/client will map from the local
representation to a "general" mapping.  For current Solaris
implementation we do the easy thing and map the uid to a user@domain
with the help of the getpwuid() function.  This is then backended by
your favorite name service: nis, nis+, ldap, /etc/passwd.

> > X509 DN's, available as an SPKM3 name, and kerberos v5 names have different 

And this has been my interpretation of the owner and owner_group
attributes as well.

>      turn it into a uid.  That's just wrong. 

Even if the client supported SPKM3, that could have APIs available
where the owner and owner_group attributes are passed through without
the translation to the traditional Unix API.  If so, that API would
like to be in an general naming domain (user@domain) and not in the
context of the underlying security used for NFSv4 access.

Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 14 Jun 2002 15:47:28 -0500

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

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.

> have to be mapped to one another.

Certainly they have to map: principal <-> uid <-> owner

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

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

> this argues that you store something that identifies the
> >      equivalence class,
> 

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?  

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

> rpctransport format as the OWNER.

It could do that and it could also map to a potentially more general
name that would allow for flexibility at the client.

> i also think it's wrong to return a unix OWNER name from a request secured by 

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.

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

Spencer

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Mon, 17 Jun 2002 11:04:28 -0400

> may not look like a security principal.  It may be a regular unix user

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?

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

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

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

> mapping mechanisms become more common.  APIs also need to adapt as

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!

> 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. 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. it doesnt give a whit 
about what the application does with the name, as well it shouldnt. so if not 
the rpc layer, and not the NFSv4 portion of the implementation, then where is 
this magic supposed to take place?

>  This may be true for some

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

-->Andy

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 18 Jun 2002 15:13:18 -0500

On Mon, William A.(Andy) Adamson wrote:
...
> Client CA v1, CN=[email-masked]"

Do you have a suggestion of how to handle the case that a file owner
does not have a name@realm for the security mechanism being used by
a particular request?

I am thinking of the configuration scenario where the server is being
accessed by a mix of say kerberos and spkm but one or the other of
those security mechanism is not fully populated by the full set of
owners of all filesystems objects being shared by the v4 server.  For
example, the spkm mechanism may not be fully populated for all owners
but doesn't need to be since not all owners use spkm.

If a request is using spkm to access a directory that has a mix of
owners, what does the server return for those owner attributes where
the owner does not have a mapping to an spkm name@realm name?

> "understand' means, map the name to a local filesystem identifier.

What I was trying to suggest was that the client software is layered
such that the RPC layer taking care of interaction with the particular
security mechanism doesn't make available APIs to map security
principals to another identifier.  Therefore, the NFS layer may not
have access to the mapping.  However, it may have access to other
types of mappings.  I know that this scenario is unlikely given the
type of APIs available but it is possible.

-- 
Spencer