Subject: [nfsv4] WG Last call for Multiple NFSv4 Domain Namespace Deployment Guidelines

From: Spencer Shepler <[email-masked]>
Date: Thu, 23 Jul 2015 16:49:33 +0000

Per Andy's email, we are starting a working group last call for this I-D

http://datatracker.ietf.org/doc/draft-ietf-nfsv4-multi-domain-fs-reqs/

You will find the text version of the draft here:

https://www.ietf.org/id/draft-ietf-nfsv4-multi-domain-fs-reqs-02.txt

Please review and let Andy and the WG know of comments/feedback.

We will close the last call on Aug 10th (please let me know if additional time is needed).

Spencer

---

From: David Noveck <[email-masked]>
Date: Thu, 23 Jul 2015 13:12:13 -0400

Let me request that we also move forward on a working group last call for
draft-ietf-nfsv4-rfc3530-migration-update.

On Thu, Jul 23, 2015 at 12:49 PM, Spencer Shepler <[email-masked]>
wrote:

>
>
> Per Andy’s email, we are starting a working group last call for this I-D
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>

---

From: Chuck Lever <[email-masked]>
Date: Thu, 23 Jul 2015 16:46:19 -0400

I’d like to see that too.

On Jul 23, 2015, at 1:12 PM, David Noveck <[email-masked]> wrote:

> Let me request that we also move forward on a working group last call for draft-ietf-nfsv4-rfc3530-migration-update.
> 
> On Thu, Jul 23, 2015 at 12:49 PM, Spencer Shepler <[email-masked]> wrote:
>  
> 

--
Chuck Lever

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 24 Jul 2015 00:03:08 -0700

We also decided to put the FlexFiles back into WG LC.

Can you start that up as well?

> On Jul 23, 2015, at 1:46 PM, Chuck Lever <[email-masked]> wrote:
>

---

From: Mike Kupfer <[email-masked]>
Date: Thu, 30 Jul 2015 13:56:06 -0700

> Please review and let Andy and the WG know of comments/feedback.

I'd be a lot happier with the last paragraph of Section 5.1.2 if we
change "can not participate" to "can not easily participate".

Also in that paragraph, I'd omit "32 bit".  The key issue (IIUC) is the
lack of an explicit domain component.  A system with 64-bit POSIX IDs
would face the same issue (though it might have an easier time working
around the problem, since it has a larger object space to play with).

Andy and Nico: thanks for writing this up.

mike

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Jul 2015 16:21:50 -0500

> change "can not participate" to "can not easily participate".

Sure.

> around the problem, since it has a larger object space to play with).

The difference between 32- and 64-bit POSIX IDs is important though.
With 32-bit IDs the system can map a great many foreign entities, but
is easily DoSed.  With 64-bit IDs that problem doesn't exist.  This is a
qualitative difference.

Internally systems should still strive to use id@domain (as it were)
qualified ID forms just because that's much simpler than keeping a
persistent mapping to the flat POSIX ID namespace.  (Implementors can
also carve out a 64-bit ID namespace for mapping ranges of foreignt
domain IDs to local ones, to lower the persistence cost, but still.)
But at the end of the day POSIX system implementors need UIDs and GIDs
for compatibility with POSIX APIs :(

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Jul 2015 16:59:37 -0500

> https://www.ietf.org/id/draft-ietf-nfsv4-multi-domain-fs-reqs-02.txt

Are both in WGLC or just the first one?

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Jul 2015 17:11:42 -0500

> https://www.ietf.org/id/draft-ietf-nfsv4-multi-domain-fs-reqs-02.txt

Comments:

 - Section 4.3, GSS isn't really just for Kerberos, so I'd like to replace this
   section's text with:

   "
   RPCSEC_GSS uses GSS-API [RFC2743] security mechanisms to securely
   authenticate users to servers.  The most common mechanism is Kerberos
   [RFC4121].

   The forms of client principal names are mechanism-specific.  For
   Kerberos these are of the form name@DOMAIN.  Sometimes authorization
   context information is delivered with authentication, but this cannot
   be counted on.  Authorization context information delivered with
   authentication has timely update considerations (i.e., generally it's
   not possible to get a timely update).

   File Access: File access decisions therefore require a wire-to-disk
   mapping of the GSS to a UID(s) and GIDs as the authorization context.

   Implementations must never blindly drop a Kerberos REALM name from a
   Kerberos principal name to obtain a POSIX username, but they may be
   configured to do so for specific REALMs.

   Meta-data setting and listing: This is the same as in Section 4.2.
   "

   The part about realm names is critical!

More later,

Nico
--

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 30 Jul 2015 22:13:26 +0000

Nico,

These are the same document - just different reference points.

Spencer

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Jul 2015 17:14:51 -0500

> These are the same document - just different reference points.

D'oh!  Ay.

---

From: Mike Kupfer <[email-masked]>
Date: Thu, 30 Jul 2015 15:23:42 -0700

> is easily DoSed.  With 64-bit IDs that problem doesn't exist.  This is a

Okay, fair enough.

mike

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Jul 2015 17:47:46 -0500

Comments:

 - Section 5.1, the items about uniquiness really mean something along
   the lines of "there can be only one logical entity responding to the
   name in question".  I mean, all names are unique... it's just whether
   one or more entities share a name that matters.

   Is this too obvious?  If not I'll propose text.

 - Section 5.1, I think the MUST in the last item can be made a SHOULD.

   Suppose a UID/SID/whatever has N names that resolve to it, and none
   are canonical: what does that mean?  Well, it means that sometimes a
   GETATTR will should one name and other times another name for the
   same entity.  That's mostly harmless, harmful only to servers that
   store name@domain instead of something else, and even then it's not
   really harmful at all if the server always includes all those aliases
   in the authorization contexts of principals.

 - Section 5.1,

   "
   Due to UID and GID collisions, stringified UID/GIDs MUST NOT be used
   in a multiple NFSv4 domain file system.
   "

   Well, what this means is that the multi-domain-capable server MUST
   reject such and the multi-domain-capable client MUST NOT send them.
   It's possible that a dumber client will be speaking to the
   server, so I think it's best to just say that the server MUST reject
   them.

   Also, it's not outside the realm of useful to have clients and
   servers that send stringified UIDs/GIDs in a multi-domain
   environment, provided that the clients and servers agree on a single
   common domain for them.  We have no operation for reaching such
   agreement however, so it's good that we don't mention it.

   Stringified id@domain might well turn out to be useful someday.  In
   fact, it definitely would be!  But it's too late I guess for that
   now.

 - Section 5.1, last paragraph.  Remove this!  We should never, ever
   speak of truncating name@REALM carelessly.  What some of us refer to
   as "realm-chopping" is a very dangerous and difficult to remediate
   habit never ever to be encouraged in others.

   In any case, the nsswitch generally never strips @domain out of
   names!  Do not assume that it does!

 - Section 5.2, AUTH_SYS should be labeled obsolete and of limited
   utility.

   (Though a form that has no limit on GID list is in widespread use and
   is significantly more useful than -though as insecure as- AUTH_SYS as
   specified.  We should note both of these facts.)

 - Section 5.2.1 needs wordsmithing (number agreement and such).

 - "nsswitch" probably needs a definition.

 - Section 5.2.1, last para, the need to map authenticated principal
   names to authorization contexts is always present (except for
   AUTH_SYS, and uses of RPCSEC_GSSv3 where only a client but not a user
   is authenticated but where the client assert's the user's
   authorization context and the server accepts some of these
   assertions), so remove or re-write this paragraph.

 - RPCSEC_GSSv3 should be mentioned, perhaps.

 - Section 6, third paragraph: why is this not just always REQUIRED???

 - Section 6, thitd para: who does not assume the listed things?
   Certainly a real implementation in a real deployment needs to know
   those things.  Do we mean that the NFSv4 specification does not
   assume these things?

 - Section 8, well, no, this document is very much about security, and
   is littered with security-relevant RFC2119 language...

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Jul 2015 17:49:06 -0500

> > is easily DoSed.  With 64-bit IDs that problem doesn't exist.  This is a

Reading the actual I-D, I think the "32bit" thing does need to be
dropped.  When responding to your comment I assumed a lot more context.
Sorry about that.

Nico
--

---

From: David Noveck <[email-masked]>
Date: Fri, 31 Jul 2015 06:52:16 -0400

> Section 8, well, no, this document is very much about security, and

Agree that section 8 needs work, but I think "littered" is the wrong word

---

From: "Adamson, Andy" <[email-masked]>
Date: Fri, 31 Jul 2015 13:04:58 +0000

> On Jul 30, 2015, at 4:56 PM, Mike Kupfer <[email-masked]> wrote:
> 
> Spencer Shepler wrote:
> 
> change "can not participate" to "can not easily participate”.

OK - I agree.

> around the problem, since it has a larger object space to play with).

Yes - good point

> Andy and Nico: thanks for writing this up.

Thanks for the review

—>Andy

---

From: "Adamson, Andy" <[email-masked]>
Date: Fri, 31 Jul 2015 15:51:17 +0000

> On Jul 30, 2015, at 6:47 PM, Nico Williams <[email-masked]> wrote:
> 
> - Section 5.1, the items about uniqueness really mean something along
>   name in question".  I mean, all names are unique…

Huh? 

> it's just whether

Um - that is what the concept of a "unique name" means: that only one entity has the name, which has meaning given the scope of uniqueness.

I think “unique within the multiple NFS v4 domain namespace” says exactly what is needed to be said,
as does "unique within the specified NFSv4 domain”

>   Is this too obvious?  If not I'll propose text.

One purpose of this document is to state all requirements, obvious or not. I think the text is fine.

> - Section 5.1, I think the MUST in the last item can be made a SHOULD.

Just to be clear - this is the MUST you think can be made a SHOULD:

  o  Every local representation of a user and of a group MUST have a
      canonical name@domain, and it must be possible to return the
      canonical name@domain for any identity stored on disk, at least
      when required infrastructure servers (such as name services) are
      online.

>   same entity.  

Which means that all of the clients who get one of the multiple name@domain names for the UID/SID/whatever will only display one name in ACLs - which is really confusing.

But the real problem is that this also means that ALL of the servers in the multi-domain NFSv4 namespace that want to give access to the remote entity in their NFSv4 domain would need to map ALL of the NFSv4 name@domain names for that entity to the local representation of the file system for that entity that the server exports. How does a server from a remote realm know when to do that? The server gets a SETATTR to place an ACL on a file from one of these multiple NFSv4 name@domain names from the remote NFSv4 domain that the entity belongs to. If it does not have a local representation for the name@domain, it creates one. How does it know that it doesn’t already have a local representation for that entity under a different name@domain.

> That's mostly harmless,

I disagree as it forces all servers in the NFSv4 multi-domain namespace to support it.

Furthermore, I see no reason to allow it. Where is the up side for this added complexity??

> harmful only to servers that

Yes - that is a good addition.

> - Section 5.1, last paragraph.  Remove this!

Just to be clear: 

   Note that for stand-alone NFSv4 domains it does not matter if the
   choice of the NFSv4 domain name is replicated by another stand-alone
   NFSv4 domain deployment.  Indeed, if a stringified UID/GID scheme is
   used, or just UNIX mode bits are used (NFSv4 ACLs are not set or
   listed) and the simple nsswitch interface that strips the @domain and
   the @REALM is used, then the domain portion of name@domain can be
   ignored, and even be different for each client and server in the
   domain.

>  We should never, ever

I added this paragraph because I have encountered such use, and it is allowed. The point being that there are many single domain configurations that won’t work in the multi-domain space, and this is a common configuration where either the kerberos REALM == NFSv4 domain and/or the domain/REALM portion is removed. Noting that truncating the REALM or domain is dangerous is a good idea, but mentioning it as a use case is OK.

That said, changing  "that strips the @domain and the @REALM is used,” to “where the single Kerberos REALM name equals the NFSv4 domain,” is fine with me.
> - Section 5.2, AUTH_SYS should be labeled obsolete and of limited

That is beyond the scope of this document, where only multi-domain specific constraints are mentioned.

“ AUTH_SYS MUST NOT be used in a multiple NFSv4 domain file system.” is much stronger than ‘obsolete and of limited utility’

>   specified.  We should note both of these facts.

Not in this document - only the usefulness WRT NFSv4 multi-domain file systems which is zero.

> )

OK

> 
> - Section 5.2.1, last para,

Just to be clear, here is the last paragraph of section 5.2.1

   Multiple security services per NFSv4 domain is allowed, and brings
   the issue of mapping multiple Kerberos 5 principal@REALMs to the same
   local ID.  Methods of achieving this are beyond the scope of this
   document.

> the need to map authenticated principal
>   AUTH_SYS,

AUTH_SYS MUST NOT be used, so no need to mention it.

> and uses of RPCSEC_GSSv3 where only a client but not a user
>   assertions), so remove or re-write this paragraph
> 

The point of the last paragraph in 5.2.1 is that multiple security servers per NFSv4 domain is allowed.

> 
> - Section 6, third paragraph:

Section 6, third paragraph:

   In the multiple NFSv4 domain case where a principal is seeking access
   to files on an NFSv4 server not in the principal's home NFSv4 domain,
   the server is REQUIRED to obtain in a secure manner the principal's
   authorization context information from an authoritative source.  In
   this case there is no assumption of:

>  why is this not just always REQUIRED???

One purpose of this document is to state all requirements, obvious or not.

> - Section 6, thitd para: who does not assume the listed things?

Don’t know what listing you are referring to.

>   is littered with security-relevant RFC2119 language…

   There are no security considerations introduced by this document
   beyond those described in NFSv4.0 [I-D.ietf-nfsv4-rfc3530bis] and
   NFSv4.1 [RFC5661]

OK - perhaps you have some text?

—>Andy

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Jul 2015 11:49:15 -0500

On Fri, Jul 31, 2015 at 03:51:17PM +0000, Adamson, Andy wrote:
> Which means that all of the clients who get one of the multiple
> name@domain names for the UID/SID/whatever will only display one name
> in ACLs - which is really confusing.

I don't follow.

> But the real problem is that this also means that ALL of the servers
> in the multi-domain NFSv4 namespace that want to give access to the
> remote entity in their NFSv4 domain would need to map ALL of the NFSv4
> name@domain names for that entity to the local representation of the
> file system for that entity that the server exports. How does a server

They have to anyways, when there is a local representation.

> from a remote realm know when to do that? The server gets a SETATTR to
> place an ACL on a file from one of these multiple NFSv4 name@domain
> names from the remote NFSv4 domain that the entity belongs to. If it
> does not have a local representation for the name@domain, it creates
> one. How does it know that it doesn’t already have a local
> representation for that entity under a different name@domain.

You're confusing having a canonical name with resolving to the same
entity.  A canonical ID *is* necessary (e.g., a SID), but it needn't be
a name@domain.

> I disagree as it forces all servers in the NFSv4 multi-domain

See above.

> I added this paragraph because I have encountered such use, and it is
> allowed. The point being that there are many single domain

Never, ever encourage blind realm-chopping.  I and many others have
spent countless hours (at great expense) remediating messes left by
people who did it.  It's dangerous, limits sites' ability to add realms
to their environment (because that then is dangerous), and is extremely
costly to repair.  It should never, ever be allowed, ever, no, no, no.

No.

> configurations that won’t work in the multi-domain space, and this is
> a common configuration where either the kerberos REALM == NFSv4 domain
> and/or the domain/REALM portion is removed. Noting that truncating the
> REALM or domain is dangerous is a good idea, but mentioning it as a
> use case is OK.

No.  No.  A million times no.  No.

> That said, changing  "that strips the @domain and the @REALM is used,”
> to “where the single Kerberos REALM name equals the NFSv4 domain,” is
> fine with me.

That's still not good enough.  s/equals/is known to be equivalent to/
makes it OK.  String equality checks (with or without case-sensitivity,
which would bring I18N into the picture, which you don't want) are not
good enough.

> specific constraints are mentioned.

Making it obsolete in a formal sense is out of scope, but we're not
doing that.  We should say it's obsolete even though we're not updating
any RFCs to make officially obsolete.

> “ AUTH_SYS MUST NOT be used in a multiple NFSv4 domain file system.” is much stronger than ‘obsolete and of limited utility’

Yes, but readers should know why.

> AUTH_SYS MUST NOT be used, so no need to mention it.

The parenthetical was not suggested text.  None of that comment was.

> The point of the last paragraph in 5.2.1 is that multiple security servers per NFSv4 domain is allowed.

What does "multiple security servers" refer to?

> One purpose of this document is to state all requirements, obvious or not.

I meant that the first part of the first sentence of that para, up to
the comma, can be removed.  There's no need to qualify this requirement.

> Don’t know what listing you are referring to.

"In this case there is no assumption of: <list>"

> >   those things.  Do we mean that the NFSv4 specification does not

I'm asking who is [not] doing the assuming?  It's a wordsmithing
question.

> OK - perhaps you have some text?

A good start would be:

   This RFC discusses security throughout.  All the security
   considerations of the relevant protocols, such as NFSv4.0, NFSv4.1,
   RPCSEC_GSS, GSS-API, LDAP, and others, apply.  [Add references.]

   Authentication and authorization across administrative domains
   presents security considerations, most of which are treated
   elsewhere, but we repeat some of them here:

    - latency in propagation of revocation of authentication credentials
    - latency in propagation of revocation of authorizations
    - latency in propagation of granting of authorizations
    - complications in establishing a foreign domain's users' complete
      authorization context: only parts may be available to servers
    - privacy considerations in a federated environment

   Most of these are security considerations of the mechanisms used to
   authenticate users to servers and servers to users, and of the
   mechanisms used to evaluate a user's authorization context.  We don't
   treat them fully here, but implementors should study the protocols in
   question to get a more complete set of security considerations.

   Note that clients/users may also need to evaluate a server's
   authorization context when using labeled security (e.g., is the
   server authorized to handle content at a given security level, for
   the given compartments).  Even when not using labeled security, since
   there could be many realms (credential issuer) for a given server,
   it's important to verify that the server a client is talking to has a
   credential for the name the client has for the server, and that that
   credential's issuer (i.e., its realm) is allowed to issue it.
   Usually the service principle realm authorization function is
   implemented by the security mechanism, but the implementor should
   check this.

   Implementors may be tempted to assume that realm (or "issuer") and
   domain are roughly the same thing, but they are not.  Configuration
   and/or lookup protocols (such as LDAP) and associated schemas are
   generally required in order to evaluate a user principal's
   authorization context.  In the simplest scheme a server has access to
   a database mapping all known principal names to usernames whose
   authorization context can be evaluated using operating system
   interfaces that deal in usernames rather than principal names.

Nico
--

---

From: "Adamson, Andy" <[email-masked]>
Date: Fri, 31 Jul 2015 18:38:19 +0000

> On Jul 31, 2015, at 12:49 PM, Nico Williams <[email-masked]> wrote:
> 
>> in ACLs - which is really confusing.

"Suppose a UID/SID/whatever has N names that resolve to it, and none are canonical”

 OK. Say [email-masked] and [email-masked] both map to UID 2002.

"Well, it means that sometimes a GETATTR will should one name and other times another name for the
 same entity."

OK. Say UID 2002 is the owner of file FOO on an NFSv4.1 server. A client performs an NFSv4.1 getacl on file FOO and the GETATTR call returns [email-masked] as the owner of the file. Then the client does another getacl on the file FOO and this time the GETATTR call returns [email-masked] as the owner.

That is really confusing. 

> They have to anyways, when there is a local representation.

Servers don’t need to map multiple name@domain names to a local representation. In fact, I know of no implementation that does this. 

>> one.

>> How does it know that it doesn’t already have a local

This is a question, even without a question mark! 

> entity.  A canonical ID *is* necessary (e.g., a SID), but it needn't be

Wikipedia
	• Canonical form, data that has been canonicalized into a completely unique representation, from a previous form that had more than one possible representation

You mention SIDs. I am asserting that for scope of an NFSv4 mulit-domain file system, any name@domain is canonical, just like an SID is canonical for the Windows AD namespace, e.g. every name@domain within an NFSv4 multi-domain file system is  "a completely unique representation” of that user in the NFSv4 multi-domain name@domain name space.

So for instance, an NFSv4 domain could have multiple Kerberos realms, and a user in said NFSv4 domain could have muliple Kerberos principal names (e.g. the mulitple pricipal names are “a previous form that have more than one possible representation") all of which are mapped to the ‘canonical name@domain’ NFSv4 domain name.

In the same sense that multiple SIDs for a user breaks Windows AD namespaces, allowing multiple NFSv4 domian name@domain names breaks an NFSv4 multi-domain name space.

I see no upside to allowing more than one name@domain to map to a local representation, name@domain should be a cononical form. I stand by the paragraph.

> people who did it.  

Who still do it. It is, AFAICS, common.

> It's dangerous, limits sites' ability to add realms

So you think no? :)

Agreed - remove all reference to ‘realm-chopping’.

> which would bring I18N into the picture, which you don't want) are not

This looks fine to me:

  Note that for stand-alone NFSv4 domains it does not matter if the
  choice of the NFSv4 domain name is replicated by another stand-alone
  NFSv4 domain deployment.  Indeed, if a stringified UID/GID scheme is
  used, or just UNIX mode bits are used (NFSv4 ACLs are not set or
  listed) and the simple nsswitch interface where the single Kerberos 
  REALM name is known to be equivalent to the NFSv4 domain name, 
  then the domain portion of name@domain can be
  ignored, and even be different for each client and server in the
  domain.

> any RFCs to make officially obsolete.

No we shouldn’t. We don’t allow AUTH_SYS for NFSv4 multi-domain file systems, and that is enough.

If you want to obsolete AUTH_SYS for use by NFS, I suggest you draft an RFC.

> Yes, but readers should know why.

Well, just read the paragraph!!!!

  The AUTH_SYS security flavor uses a host-based authentication model
   where the weakly authenticated host (the NFSv4 client) asserts the
   user's authorization identities using small integers, uidNumber, and
   gidNumber [RFC2307], as user and group identity representations.
   Because this authorization ID representation has no domain component,
   AUTH_SYS can only be used in a namespace where all NFSv4 clients and
   servers share an [RFC2307] name service.  A shared name service is
   required because uidNumbers and gidNumbers are passed in the RPC
   credential; there is no negotiation of namespace in AUTH_SYS.
   Collisions can occur if multiple name services are used, so AUTH_SYS
   MUST NOT be used in a multiple NFSv4 domain file system.

OK

> What does "multiple security servers" refer to?

oops - I ment services not servers.

In 5.1.1 I note the relationship between NFSv4 domain and DNS service - and that an NFSv4 domain can span multiple DNS domains.
In 5.1.2 I note that an NFSv4 domain can only have a single local ID namespace, a ‘single name service’.
In 5.2.1 I note that an NFSv4 domain can use mulitple security services.

> the comma, can be removed.  There's no need to qualify this requirement.

Oh.

This is a requrement for the multi-domain case, and should be stated. We
are not in the business of clarifying the single domain case, which BTW can use AUTH_SYS
and therefore NOT be required to obtain anything in a secure manner as AUTH_SYS
is not secure.

So, AFAICS there is a need to qualify this requirement as it is different for the multi-domain case than for the single domain case.

> "In this case there is no assumption of: <list>”

Oh, so these two list items.

  o  Remote name service configuration knowledge

A stand alone NFSv4 domain has no “remote name service”

  o  The syntax of the remote authorization context information
      presented to the NFSv4 server by the remote name service for
      mapping to a local representation.

A stand alone NFSv4 domain has no remote name service with an unknown authorization information syntax.

The answer to "who does not assume the listed things?” is;  a stand alone NFSv4 domain.

>   domain

/domain/NFSv4 domain

> are roughly the same thing, but they are not.  Configuration

The above looks really good! I’ll add it to the next draft for review.

—>Andy

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Jul 2015 14:15:41 -0500

> Who still do it. It is, AFAICS, common.

*We* (the IETF) will not tell them it's OK, or even a thing that some
people do (except in the context of telling them the consequences and
that they must never do it).  And especially implementors, we will not
tell them it's OK.  It's much, much worse when third parties' software
does it (thus you can't fix it in a timely manner) than when in-house
software does it (thus you have a chance to get it fixed on your
schedule).

Nico
--

---

From: Andy Adamson <[email-masked]>
Date: Fri, 31 Jul 2015 15:47:04 -0400

> software does it (thus you have a chance to get it fixed on your

Got it. Agreed.

-->Andy

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Jul 2015 20:02:46 -0500

>  OK. Say [email-masked] and [email-masked] both map to UID 2002.

Yes.

> OK. Say UID 2002 is the owner of file FOO on an NFSv4.1 server. A
> client performs an NFSv4.1 getacl on file FOO and the GETATTR call
> returns [email-masked] as the owner of the file. Then the client does
> another getacl on the file FOO and this time the GETATTR call returns
> [email-masked] as the owner.
> 

Maybe, but who cares?  What if [email-masked] is renamed
[email-masked] later on in the day and now GETATTR returns
[email-masked]?  Surely you'd not prevent that.

(I always advise never to permit reuse of security identifiers, but that
doesn't preclude aliases and renaming.)

Of course, the server will have to know that joe and bob are one and the
same, and for this it's useful to have a canonincal representation of
the user.  That canonical representation may or may not be of the form
name@domain.  SIDs, for exaple, are canonical, as are UIDs.  Names
needn't be (even if there almost always is a canonical name).

> Servers don’t need to map multiple name@domain names to a local
> representation. In fact, I know of no implementation that does this. 

Eh?  Sure they do.  Windows maps them to SIDs, for example.
Illumos/Solaris maps them to UIDs/GIDs (perhaps ephemeral ones,
ultimately storing SIDs).

> You mention SIDs. I am asserting that for scope of an NFSv4
> mulit-domain file system, any name@domain is canonical, just like an
> SID is canonical for the Windows AD namespace, e.g. every name@domain
> within an NFSv4 multi-domain file system is  "a completely unique
> representation” of that user in the NFSv4 multi-domain name@domain
> name space.

No, name@domain is what appears on the wire (let's ignore for now
that this was a mistake).  Are there any servers that actually store
name@domain in file metadata?  Windows doesn't.  Solaris/Illumos
doesn't.  No Linux or BSD does either to my knowledge.  Maybe some
proprietary server does, but if so, please do tell.

And again, surely you're not excluding changes in what an entity's
canonical name is...

> So for instance, an NFSv4 domain could have multiple Kerberos realms,
> and a user in said NFSv4 domain could have muliple Kerberos principal
> names (e.g. the mulitple pricipal names are “a previous form that have
> more than one possible representation") all of which are mapped to the
> ‘canonical name@domain’ NFSv4 domain name.

Why bring principal names into this discussion?

> In the same sense that multiple SIDs for a user breaks Windows AD
> namespaces, allowing multiple NFSv4 domian name@domain names breaks an
> NFSv4 multi-domain name space.

No, multiple SIDs are even supported (see "historical SIDs").  But there
is a canonical SID for any user, this is true, though it isn't
necessarily the case that only that SID appears on disk: because the
whole point is that the user's SID had to change (e.g., because of
NT4->AD migration) and finding every file in the universe with the old
SID in order to change it is ETOOHARD.

> I see no upside to allowing more than one name@domain to map to a
> local representation, name@domain should be a cononical form. I stand
> by the paragraph.

I see no upside in not allowing it.  It's unnecessary.

> Agreed - remove all reference to ‘realm-chopping’.

OK.

>   ignored, and even be different for each client and server in the

I believe that paragraph is simply not necessary (this is the
*multi-domain* document).  It is distracting and suggestive of very much
the wrong thing.  Just remove it.

> systems, and that is enough.

Then maybe we should remove all of section 4.  Why describe things that
are out of scope?

> oops - I ment services not servers.

That's clearer.  Still, in so far as RPCSEC_GSSv3 can completely replace
all uses of AUTH_SYS (because like AUTH_SYS, and unline RPCSEC_GSSv1/2
it allows the client to assert / contribute knowledge of the user
process' authorization context), we should mention it.

> This is a requrement for the multi-domain case, and should be stated.
> We are not in the business of clarifying the single domain case, which
> BTW can use AUTH_SYS and therefore NOT be required to obtain anything
> in a secure manner as AUTH_SYS is not secure.

Maybe so, but AUTH_SYS is something we can pretend to be secure for the
purpose of this paragraph.  (Indeed, we were always supposed to pretend
that AUTH_SYS was secure.)

RPCSEC_GSSv3 allows the server to grant none, part, or all of a client's
assertions about a user process' authorization context.  In this case
the client might be the only authoritative source about the user's
authorization context.  (This is useful for diskless-ness, for
filesystems "owned" by a client.)  AUTH_SYS is the same, and as secure
if you believe in the client port < 1024 unicorn (or use IPsec).

Therefore I think readers will be best served by removing that clause.

> A stand alone NFSv4 domain has no “remote name service”

NFSv4 domains don't have "remote service names".  I don't know what that
would mean.

> The answer to "who does not assume the listed things?” is;  a stand alone NFSv4 domain.

The immediately preceding text says "In the multiple NFSv4 domain case
...", so we're talking about that, not stand-alone domains.

Incidentally, I think "ad-hoc" is a much better ajective here than
"stand-alone".

Sure.

Nico
--