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

From: "Adamson, Andy" <[email-masked]>
Date: Tue, 4 Aug 2015 16:50:20 +0000

> On Jul 31, 2015, at 9:02 PM, Nico Williams <[email-masked]> wrote:
> 
> On Fri, Jul 31, 2015 at 06:38:19PM +0000, Adamson, Andy wrote:
>>> On Jul 31, 2015, at 12:49 PM, Nico Williams <[email-masked]> wrote:
>>> On Fri, Jul 31, 2015 at 03:51:17PM +0000, Adamson, Andy wrote:
>>>> On Jul 30, 2015, at 6:47 PM, Nico Williams <[email-masked]> wrote:
>>>>> - 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.
> 
>> "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.
> 
> 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.
>> 
>> That is really confusing. 
> 
> 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).
> 
>>>> 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.
>> 
>> 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.

 Here is the paragraph in question

   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.

Thinking about this over the weekend, I’ve come to agree that we don’t need to say
anymore than RFC 5661 does about translation between name@domain and local representation in Section 5.9

I agree to remove the paragraph.

> 
>>>>> 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.
>> 
>> Agreed - remove all reference to ‘realm-chopping’.
> 
> OK.
> 
>> 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.
> 
> 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.

Alright. The stand alone domain examples are enough.

> 
>>>>> - Section 5.2, AUTH_SYS should be labeled obsolete and of limited
>>>>> utility.
>>>> 
>>>> That is beyond the scope of this document, where only multi-domain
>>>> 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.

Perhaps in the Security Considerations Section we could say more about AUTH_SYS.

>> 
>> No we shouldn’t. We don’t allow AUTH_SYS for NFSv4 multi-domain file
>> systems, and that is enough.
> 
> Then maybe we should remove all of section 4.  Why describe things that
> are out of scope?

> 
>>>>> - RPCSEC_GSSv3 should be mentioned, perhaps.
>>>> 
>>>> 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?
>> 
>> 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.

I suggest the security consideration section.

I’ll gather the comments on draft-ietf-nfsv4-multi-domain-fs-reqs-02 into a draft-03 and we’ll take it from there.

—>Andy

> 
>>>>> - 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.
>>> 
>>> 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.
>> 
>> 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.
> 
> 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.
>>>>> - Section 6, thitd para: who does not assume the listed things?
>>>> 
>>>> Don’t know what listing you are referring to.
>>> 
>>> "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”
> 
> 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”.
> 
>>>> OK - perhaps you have some text?
>>> 
>>> A good start would be:
>> 
>> /domain/NFSv4 domain
> 
> Sure.
> 
> Nico
> --

---

From: Tom Haynes <[email-masked]>
Date: Tue, 4 Aug 2015 10:16:27 -0700

Hi Spencer,

Have we started WG LC again for the flex file document?

Thanks,
Tom

> On Jul 24, 2015, at 12:03 AM, Thomas Haynes <[email-masked]> wrote:
> 
> 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:
>> 
>> 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:
>>> 
>>> 
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> nfsv4 mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>> 
>>> 
>>> _______________________________________________
>>> nfsv4 mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>> 
>> --
>> Chuck Lever
>> 
>> 
>> 
>> _______________________________________________
>> nfsv4 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: David Noveck <[email-masked]>
Date: Tue, 4 Aug 2015 15:33:18 -0400

> I’ll gather the comments on draft-ietf-nfsv4-multi-domain-fs-reqs-02 into
a draft-03 and we’ll take it from there.

If that happens in the next few days, I'll still be OK with  the current
8/10 completion date for WGLC.  If anybody
thinks they will need more time, please speak up.

---

From: Andy Adamson <[email-masked]>
Date: Fri, 7 Aug 2015 13:54:22 -0400

I just submitted draft-ietf-nfsv4-multi-domain-fs-reqs-03 where I
addressed all draft-02 comments, hopefully to everyones satisfaction.

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

-->Andy

---

From: David Noveck <[email-masked]>
Date: Fri, 7 Aug 2015 14:00:38 -0400

I was in the middle of my review of -02 and will update it to reflect the
changes made in -03.  I hope to be able to get that done by the original
date (8/10) for completing WGLC.
On Aug 7, 2015 1:54 PM, "Andy Adamson" <[email-masked]> wrote:

> >> I’ll gather the comments on draft-ietf-nfsv4-multi-domain-fs-reqs-02
> into
> >> anymore than RFC 5661 does about translation between name@domain and
> local
> >> representation in Section 5.9
> >>
> >> I’ll gather the comments on draft-ietf-nfsv4-multi-domain-fs-reqs-02
> into
> >> >>>> One purpose of this document is to state all requirements, obvious
> or
> >> >>>> not.
> >> >>>

---

From: "Adamson, Andy" <[email-masked]>
Date: Fri, 7 Aug 2015 18:05:50 +0000

> On Aug 7, 2015, at 2:00 PM, David Noveck <[email-masked]> wrote:
> 
> I was in the middle of my review of -02 and will update it to reflect the changes made in -03.  I hope to be able to get that done by the original date (8/10) for completing WGLC.

OK, Thanks. I did just notice that while I added a reference for RPCSEC_GSSv3, I did not use the reference in the last paragraph of section 5.2 as I should have….

—>Andy

---

From: Mike Kupfer <[email-masked]>
Date: Fri, 07 Aug 2015 11:32:40 -0700

> addressed all draft-02 comments, hopefully to everyones satisfaction.

I'm satisfied. :-)

thanks,
mike

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 12 Aug 2015 17:57:06 +0000

WG last call has closed.  Are there any other comments?  Andy, I assume you will have one more update and then we will be ready for IESG review, etc.?

From: nfsv4 [mailto:[email-masked]] On Behalf Of Spencer Shepler
Sent: Thursday, July 23, 2015 9:50 AM
To: NFSv4 <[email-masked]>
Subject: [nfsv4] WG Last call for Multiple NFSv4 Domain Namespace Deployment Guidelines

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

Spencer

---

From: "Adamson, Andy" <[email-masked]>
Date: Wed, 12 Aug 2015 18:02:39 +0000

> On Aug 12, 2015, at 1:57 PM, Spencer Shepler <[email-masked]> wrote:
> 
>  

Yes. I’ll send in the update by day’s end tomorrow, caveat any more comments.

—>Andy

---

From: Andy Adamson <[email-masked]>
Date: Fri, 14 Aug 2015 12:29:41 -0400

Draft 04 of draft-ietf-nfsv4-multi-domain-fs-reqs has just been
submitted.  Caveat more WG comments - I believe we are ready for IESG
review, etc...

-->Andy

On Wed, Aug 12, 2015 at 1:57 PM, Spencer Shepler <[email-masked]> wrote:
>
>
> WG last call has closed.  Are there any other comments?  Andy, I assume you
> will have one more update and then we will be ready for IESG review, etc.?
>
>
>

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 14 Aug 2015 19:32:38 +0000

Thanks, Andy.

-----Original Message-----
From: Andy Adamson [mailto:[email-masked]] 
Sent: Friday, August 14, 2015 9:30 AM
To: Spencer Shepler <[email-masked]>
Cc: NFSv4 <[email-masked]>
Subject: Re: [nfsv4] WG Last call for Multiple NFSv4 Domain Namespace Deployment Guidelines

Draft 04 of draft-ietf-nfsv4-multi-domain-fs-reqs has just been submitted.  Caveat more WG comments - I believe we are ready for IESG review, etc...

-->Andy

On Wed, Aug 12, 2015 at 1:57 PM, Spencer Shepler <[email-masked]> wrote:
>
>
> WG last call has closed.  Are there any other comments?  Andy, I 
> assume you will have one more update and then we will be ready for IESG review, etc.?
>
>
>
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdatatr
> acker.ietf.org%2fdoc%2fdraft-ietf-nfsv4-multi-domain-fs-reqs%2f&data=0
> 1%7c01%7csshepler%40microsoft.com%7c028c8749980c4b3b2ab108d2a4c58ea4%7
> c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3QF81DRBbHRfqAgfie3Ve1DWxu
> VtYUtnVefm%2f65WYfY%3d
>
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> etf.org%2fid%2fdraft-ietf-nfsv4-multi-domain-fs-reqs-02.txt&data=01%7c
> 01%7csshepler%40microsoft.com%7c028c8749980c4b3b2ab108d2a4c58ea4%7c72f
> 988bf86f141af91ab2d7cd011db47%7c1&sdata=jLHCasyPYhjoS9WoNn5bxZfT0NMYAm
> TO2MRaeUTpIX8%3d
>
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> etf.org%2fmailman%2flistinfo%2fnfsv4&data=01%7c01%7csshepler%40microsoft.com%7c028c8749980c4b3b2ab108d2a4c58ea4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ZkXabPU9gWcv443HS05R%2fZHZRvvY1Kxqo03P6ziE4BE%3d
>