Subject: Draft of new section 5.6

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 21 Jun 2002 06:32:27 -0700

The following is based on section 5.6 as it is in the June 12 draft (http://www.nfsv4.org/rfc3010updates/draft-01-03/draft-ietf-nfsv4-rfc3010bis-01-03.txt and is intended to replace that section.  There would be some additional minor changes to go with it, such as adding error codes, etc.  However, section 5.6 has the bulk of the changes that would be required so I'm focusing on it.  Once we come to consensus on this,
I'll come up with a draft spec (based on the then-most-current draft)
that includes a new section 5.6 and all the other changes that go with
it.

5.6.  Interpreting owner and owner_group

   The recommended attributes "owner" and "owner_group" (and also users
   and groups within the "acl" attribute) are represented in terms of 
   a UTF-8 string.  To avoid a representation that is tied to a 
   particular underlying implementation at the client or server,
   the use of the UTF-8 string has been chosen.  Note that section 6.1
   of [RFC2624] provides additional rationale.  It is expected that the
   client and server will have their own local representation of owner
   and owner_group that is used for local storage or presentation to the
   end user.  Therefore, it is expected that when these attributes are
   transferred between the client and server that the local
   representation is translated to a syntax of the form
   "user@dns_domain".  This will allow for a client and server that do
   not use the same local representation the ability to translate to a
   common syntax that can be interpreted by both.

   Similarly, security principals may be represented in different 
   ways by different security mechanisms.  Servers normally translate 
   these representations into a common format, generally that used
   by local storage, to serve as a means of identifying the users
   corresponding to these security principals.  When these local
   identifiers are translated to the form of the owner attribute, 
   associated with files created by such principals they identify, 
   in a common format, the users associated with each corresponding 
   set of security principals.  

   The translation used to interpret owner and group strings 
   is not specified as part of the protocol.  This allows various 
   solutions to be employed.  For example, a local translation 
   table may be consulted that maps between a numeric id to the 
   user@dns_domain syntax.  A name service may also be used to
   accomplish the translation.  A server may provide a more general
   service, not limited by any particular translation (which would
   only translate a limited set of possible strings) by storing the
   owner and owner_group attributes in local storage without any 
   translation or it may augment a translation method by storing
   the entire string for attributes for which no translation is
   available while using the local representation for those cases
   in which a translation is available.

   Servers that do not provide support for all possible values of
   the owner and owner_group attributes, should return an error
   (NFS4ERR_BADOWNER) when a string is presented that has no translation,
   as the value to be set for a SETATTR of the owner, owner_group,
   or acl attributes.  When a server does accept an owner or owner_group
   value as valid on a SETATTR (and similarly for the owner and group
   strings in an acl), it is promising to return that same string
   when a corresponding GETATTR is done.  Configuration changes and
   ill-constructed name translations (those that contain aliasing) may
   make that promise impossible to honor.  Servers should make 
   appropriate efforts to avoid a situation in which these attributes
   have their values changed when no real change to ownership has
   occurred.  

   The "dns_domain" portion of the owner string is meant to be a DNS 
   domain name.  For example, [email-masked].  Servers should accept as
   valid a set of users for at least one domain.  A server may treat
   other domains as having no valid translations.  A more general 
   service is provided when a server is capable of accepting users
   for multiple domains, or for all domains, subject to security 
   constraints.

   In the case where there is no translation available to the client or
   server, the attribute value must be constructed without the "@".
   Therefore, the absence of the @ from the owner or owner_group
   attribute signifies that no translation was available at the sender
   and that the receiver of the attribute should not use that string as
   a basis for translation into its own internal format.  Even though 
   the attribute value can not be translated, it may still be useful.  
   In the case of a client, the attribute string may be used for local 
   display of ownership.

   To provide a greater degree of compatibility with previous versions 
   of NFS (i.e. v2 and v3), which identified users and groups by 32-bit 
   unsigned uid's and gid's, owner and group strings that consist of 
   decimal numeric values with no leading zeros can be given a special 
   interpretation by clients and servers which choose to provide such
   support.  The receiver may treat such a user or group string as
   representing the same user as would be represented by a v2/v3 uid or
   gid having the corresponding numeric value.  A server is not obligated
   to accept such a string, but may return an NFS4ERR_BADOWNER instead.
   To avoid this mechanism being used to subvert user and group translation,
   so that a client might pass all of the owners and groups in numeric 
   form, a server SHOULD return an NFS4ERR_BADOWNER error when there is a
   valid translation for the user or owner designated in this way.  In that
   case, the client must use the appropriate name@domain string and not the
   special form for compatibility.

   The owner string "nobody" may be used to designate an anonymous user,
   which will be associated with a file created by a security principal 
   that cannot be mapped through normal means to the owner attribute.

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 24 Jun 2002 17:04:26 -0500

> that includes a new section 5.6 and all the other changes that go with

Looks like Dave's suggested text is appropriate based on the
discussion to date.  If there are no strong objections, I am going to
work with Dave to integrate this into the next draft.  

Spencer