Subject: [nfsv4] Normalizations in -30 (Re: rfc3530bis -30: Approach to case insensitivity (5.10))

From: Nico Williams <[email-masked]>
Date: Thu, 9 Jan 2014 18:52:01 -0600

While we're at it, and with respect to normalization, I do think that
the ZFS approach (normalization-insensitivity) is superior to the
alternatives (normalize-on-CREATE/LOOKUP or just-don't-normalize).  In
any case, it's worth having informative text about the relative merits
and pitfalls of all three approaches, even if all three are MAY.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 9 Jan 2014 18:56:14 -0600

Hmm, the text in section 12.3, second bullet item, conflicts with the
text in section 12.8, last bullet item.

---

From: Nico Williams <[email-masked]>
Date: Thu, 9 Jan 2014 18:58:34 -0600

The text in section 12.3 may not be representative of ZFS, for
example.  IIRC if configured to not reject non-UTF-8 ZF will still be
n-i at least for the apparently-UTF-8 names.  This must neither be
ignored nor required to not be implemented.

---

From: Nico Williams <[email-masked]>
Date: Thu, 9 Jan 2014 19:02:11 -0600

Section 5.9 says:

   o  The user or group may be returned in a different form, due to
      normalization issues, although it will always be a canonically
      equivalent string.

What will make sure that user/group names on the wire will be a
canonically equivalent form of the [presumably] original?

Is that canonical equivalence as in the Unicode canonical equivalence,
as in normalization?

What if a user/group is renamed?  or has aliases?  or what if the
server does not normalize user/group names in any context?

---

From: Nico Williams <[email-masked]>
Date: Thu, 9 Jan 2014 19:03:43 -0600

What's this about:

   RPCSEC_GSS, via GSS-API, normalizes access to mechanisms that provide
   security services.  Therefore, NFSv4 clients and servers MUST support
   the Kerberos V5 security mechanism.

?

In what sense does GSS normalize access to security mechanisms, and
how does that lead to the requirement that Kerberos be implemented?

---

From: "Black, David" <[email-masked]>
Date: Thu, 9 Jan 2014 20:21:07 -0500

This is an example of problems I have with use of "canonical equivalence"
in this draft, and I didn't notice this one.

IMHO, the best thing is to avoid that concept, among other reasons because
it can lead to the mistaken impression that there is a single canonical
form for Unicode strings in NFSv4.0, which is simply not true.

How about shortening the text as follows?:

OLD
    o  The user or group may be returned in a different form, due to
       normalization issues, although it will always be a canonically
       equivalent string.
NEW
    o  The user or group may be returned in a different but equivalent
       form due to translation.

I changed "normalization" to "translation" because normalization generally
refers to Unicode normalization in this draft, and there could be more than
that going on.  The answer to "What does equivalence mean?" is "Whatever
the server thinks it means." courtesy of this text further up in the section:

   The translation used to interpret owner and group strings is not
   specified as part of the protocol.  This allows various solutions to
   be employed.

In particular, one possible solution is to round-trip the translation
between protocol and internal forms.

Thanks,
--David

> -----Original Message-----
> From: Nico Williams [mailto:[email-masked]]
> Sent: Thursday, January 09, 2014 8:02 PM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: [nfsv4] Normalizations in -30 (Re: rfc3530bis -30: Approach to
> case insensitivity (5.10))
> 
> Section 5.9 says:
>

---

From: Nico Williams <[email-masked]>
Date: Thu, 9 Jan 2014 20:13:55 -0600

>     o  The user or group may be returned in a different but equivalent

Yes, that works.

Another issue is that there's no question of "returned" user/group
names.  There's SETATTR, and there's GETATTR.  Without any mechanism
for ensuring that no other SETATTRs intervene between one SETATTR and
a GETATTR on the same file, there's no way a client should expect the
same user/group names.

There's actually quite a bit in the way of translation that a server
could do, including drop ACL entries the server doesn't like, or
accept ones it won't interpret (say, because of MAC).

In particular clients should not be checking that the
owner/group/ACL/mode of a file is as it thought it was setting it
immediately after setting it.  But the business about returning these
things might give client implementors the wrong idea.

> between protocol and internal forms.

There may be aliases.  We cannot ask servers to recall which one a
client used when changing a file's owner/group/ACL.

Nico
--

---

From: "McDonald, Alex" <[email-masked]>
Date: Fri, 10 Jan 2014 14:57:35 +0000

> 
> In particular, one possible solution is to round-trip the translation between
> protocol and internal forms.

Note from http://www.unicode.org/faq/casemap_charprop.html 

Q: Are case mappings reversible?

A: No, case mapping loses information and thus does not allow for a round trip.

Alex McDonald
Standards & Industry Associations Group
CTO Office
NetApp
+44 7795 046686 Mobile Phone
[email-masked]
twitter: @alextangent
Follow us:

---

From: "Black, David" <[email-masked]>
Date: Fri, 10 Jan 2014 10:06:42 -0500

Which is acceptable behavior in this case - please read Section 5.9 in the draft.

Thanks,
--David

> From: McDonald, Alex [mailto:[email-masked]]
> Sent: Friday, January 10, 2014 9:58 AM
> To: Black, David; Nico Williams
> Cc: [email-masked]
> Subject: RE: [nfsv4] Normalizations in -30 (Re: rfc3530bis -30: Approach to

---

From: "McDonald, Alex" <[email-masked]>
Date: Fri, 10 Jan 2014 15:29:20 +0000

> Which is acceptable behavior in this case - please read Section 5.9 in the

I presume these sections apply:

<quote>
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 (for which see below) when a corresponding GETATTR is
   done.  For some internationalization-related exceptions where this is
   not possible, see below.

<quote>
The user or group may be returned in a different form, due to
      normalization issues, although it will always be a canonically
      equivalent string.

Case mapping a string means it's not possible to return a canonically equivalent string.

Alex McDonald

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 10 Jan 2014 10:41:39 -0500

Wait, we’re adding the case insensitivity insanity to the owner/group labels? How on earth is the client expected to know what language-specific rules the server is applying?

That looks like a no-fly zone to me…

Trond

On Jan 10, 2014, at 10:29, McDonald, Alex <[email-masked]> wrote:

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Noveck, David" <[email-masked]>
Date: Fri, 10 Jan 2014 11:15:49 -0500

> Case mapping a string means it's not possible to return a canonically equivalent string.

Exactly so.

The conclusion that can be drawn is that one should not (or "SHOULD NOT" or "MUST NOT" or "had better not") do case mapping on owner or group strings.

Maybe this point should be made explicitly in the spec.  Otherwise I can see people getting confused and assuming that, in a filesystem which is not case-preserving, SETATTR/GETATTR of owner and owner_group may be non-case-preserving as well.

-----Original Message-----
From: nfsv4 [mailto:[email-masked]] On Behalf Of McDonald, Alex
Sent: Friday, January 10, 2014 10:29 AM
To: Black, David; Nico Williams
Cc: [email-masked]
Subject: Re: [nfsv4] Normalizations in -30 (Re: rfc3530bis -30: Approach to case insensitivity (5.10))

<quote>

<quote>

Alex McDonald

---

From: "Black, David" <[email-masked]>
Date: Fri, 10 Jan 2014 11:20:18 -0500

On rereading, I think Alex and Trond are right, and the translation cannot be
round-tripped (my mistake, sorry).  How about this (picks up Dave Noveck's
suggest to call out case mapping as something not to be done)?:

OLD
   o  The user or group may be returned in a different form, due to
      normalization issues, although it will always be a canonically
      equivalent string.
NEW
   o  The user or group may be returned in a different form, as a result
	of Unicode normalization at the server.  The result will always be
	a canonically equivalent Unicode string [Unicode1]; for example,
	case mapping of user and group strings is prohibited.

I can live with the use of the "canonical equivalence" here with the
explicit reference to Unicode.

Thanks,
--David

> From: Trond Myklebust [mailto:[email-masked]]
> Sent: Friday, January 10, 2014 10:42 AM
> To: McDonald, Alex
> Cc: Black, David; Nico Williams; [email-masked]
> Wait, we're adding the case insensitivity insanity to the owner/group labels?
> How on earth is the client expected to know what language-specific rules the
> server is applying?
> 
> That looks like a no-fly zone to me...
> 
> Trond
>

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 Jan 2014 11:12:42 -0600

>         case mapping of user and group strings is prohibited.

Nooo, no way.  We should say nothing about forms of user/group names
returned by servers other than that they are UTF-8 strings.

NEW:
   o  The user or group may be returned in a different form, as a result
        name canonicalization and/or Unicode normalization performed
        by the server.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 10 Jan 2014 12:24:54 -0500

>        name canonicalization and/or Unicode normalization performed

So if the client has 2 users: [email-masked] and [email-masked], which is perfectly legitimate in the *NIX world, then how does it deal with the above situation? To whom should it assign the files?

Note that krb5 principals are _also_ case sensitive, so there is no problem with resolving this as far as authentication goes.

Trond

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 Jan 2014 11:49:11 -0600

On Fri, Jan 10, 2014 at 12:24:54PM -0500, Trond Myklebust wrote:
> So if the client has 2 users: [email-masked] and [email-masked], which is
> perfectly legitimate in the *NIX world, then how does it deal with the
> above situation? To whom should it assign the files?

My proposed text doesn't say that the server must/should do anything at
all to the names sent by the client.  It only _permits_ the server to
canonicalize and/or normalize.

With my text it's permissible to have case-sensitive user/group
namespaces, and the client probably must get the right form on SETATTR.

With my text it's also permissible to have a server that has a
case-insensitive user/group namespace.

And it's even permissible to have case-sensitivity vary by domain.

Remember, the vast majority of implementations will do a name service
lookup (e.g., in LDAP) and will store an ID form not intended for
display (e.g., UID, GID, SID).  On GETATTR the server will once more do
a name service lookup and will return whatever the service says that
ID's name is.  Thus everything depends on the name service.

And, between the SETATTR and GETATTR a user's name might have changed.
Or another client might have done another SETATTR.

There's no way a client should expect that an owner username will be the
same when it does a GETATTR as when it set it with SETATTR.  The client
SHOULD NOT even attempt to check that GETATTR shows the server taking
the client's SETATTR correctly.

Once more, I object to the idea that we should describe what servers do
without describing any details about the boundaries between "server" and
"filesystem", and, in this case, "server" and "name service".  These
boundaries exist in 100% of the general-purpose NFSv4 server
implementations, and probably 100% of the NAS-only implementations.  The
actual normalization- and case-sensitivity/preservation semantics that
result depend on the filesystems (or, in this case, name service), not
the *server*.

Failing to note these boundaries has resulted in text like the text I
objected to in the post you were responding to.  Failure to note these
boundaries results text that fails to explain the reasons why things are
the way they are.  Yes, we're dealing with bits on the wire, but that
does not mean we can't say anything about stuff beyond those bits.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 10 Jan 2014 12:55:24 -0500

> the client's SETATTR correctly.

If I log in as [email-masked], then I would object _strongly_ to any server that allows access to my file to [email-masked].

If the server can’t store the owner correctly, then it should return NFS4ERR_BADNAME.

Note that the above is true of ACLs too, which are also covered by the GETATTR/SETATTR text.

> does not mean we can't say anything about stuff beyond those bits.

No. This is real simple: it is about matching the file authorization rules to the capabilities of the authentication scheme that is used.
If your server is trying to store an ACE for [email-masked] as something that can be interpreted as anything other than [email-masked], then it is simply broken to pieces.

Trond

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 10 Jan 2014 12:58:04 -0500

> If the server can’t store the owner correctly, then it should return NFS4ERR_BADNAME.

Err…. I mean NFS4ERR_BADOWNER.

---

From: "Noveck, David" <[email-masked]>
Date: Fri, 10 Jan 2014 13:23:02 -0500

> With my text it's also permissible to have a server that has a case-insensitive user/group namespace.

Do you know of such a server  or name service?

If not, then I don't see a reason to open up this possibility, since existing clients expect otherwise.

-----Original Message-----
From: nfsv4 [mailto:[email-masked]] On Behalf Of Nico Williams
Sent: Friday, January 10, 2014 12:49 PM
To: Trond Myklebust
Cc: McDonald, Alex; [email-masked]
Subject: Re: [nfsv4] Normalizations in -30 (Re: rfc3530bis -30: Approach to case insensitivity (5.10))

> above situation? To whom should it assign the files?

My proposed text doesn't say that the server must/should do anything at all to the names sent by the client.  It only _permits_ the server to canonicalize and/or normalize.

With my text it's permissible to have case-sensitive user/group namespaces, and the client probably must get the right form on SETATTR.

With my text it's also permissible to have a server that has a case-insensitive user/group namespace.

Remember, the vast majority of implementations will do a name service lookup (e.g., in LDAP) and will store an ID form not intended for display (e.g., UID, GID, SID).  On GETATTR the server will once more do a name service lookup and will return whatever the service says that ID's name is.  Thus everything depends on the name service.

There's no way a client should expect that an owner username will be the same when it does a GETATTR as when it set it with SETATTR.  The client SHOULD NOT even attempt to check that GETATTR shows the server taking the client's SETATTR correctly.

Once more, I object to the idea that we should describe what servers do without describing any details about the boundaries between "server" and "filesystem", and, in this case, "server" and "name service".  These boundaries exist in 100% of the general-purpose NFSv4 server implementations, and probably 100% of the NAS-only implementations.  The actual normalization- and case-sensitivity/preservation semantics that result depend on the filesystems (or, in this case, name service), not the *server*.

Failing to note these boundaries has resulted in text like the text I objected to in the post you were responding to.  Failure to note these boundaries results text that fails to explain the reasons why things are the way they are.  Yes, we're dealing with bits on the wire, but that does not mean we can't say anything about stuff beyond those bits.

Nico

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 Jan 2014 12:35:07 -0600

On Fri, Jan 10, 2014 at 12:55:24PM -0500, Trond Myklebust wrote:
> If I log in as [email-masked], then I would object _strongly_ to any
> server that allows access to my file to [email-masked].
> 

Every production-quality NFSv4 server on general purposes OSes does
something like getpwnam()/getgrname() (or an LDAP lookup, or an LSA RPC)
on the names sent by the client, then it stores UIDs, GIDs, and/or SIDs
on persistent storage.

Every last one of them.  (Actually, I've not looked at what *BSD do, but
it'd be crazy to do anything else, so I'm assuming it does this too.)

That general-purpose filesystems on general-purposes OSes store
UID/GID/SID-like identifiers has been so since the dawn of Unix
filesystems, and since the dawn of Windows NT.  It wouldn't surprise me
if this practice went back further still.

Therefore in a SETATTR..GETATTR sequence the server does canonicalize
user/group names.  Necessarily.  The server might well have created a
cached lookup entry when doing a lookup by name so that the lookup-by-ID
will produce the same name, but that will be a cache, subject to
invalidation.  In the absense of such a cache this "lookup UID/GID/SID
and store that" behavior necessarily means that the name service gets to
(but is not required to) permit aliases for users and groups.

> Note that the above is true of ACLs too, which are also covered by the

Note that the above also is true of ACL entry subject names.

> No. This is real simple: it is about matching the file authorization
> rules to the capabilities of the authentication scheme that is used.

You're mixing up authentication with authorization.

You can use Kerberos and Unix/POSIX-style authorization (UIDs and GIDs)
with and without a NIS/LDAP/whatever distributed name service.  You can
use Kerberos with Win32-style authorization (SIDs and NTFS-style ACLs).
You can use Kerberos with AFS-style authorization.  I could go on.

Authentication != authorization.

You should want (and generally get) that successful authentication of a
peer yields an authorization context (e.g., a list of group memberships,
...).

> If your server is trying to store an ACE for [email-masked] as

Every general-purpose server/filesystem stores UIDs, GIDs, or SIDs -not
name@DOMAIN strings- on disk.  If you think that is bad, good luck
getting that changed.

> something that can be interpreted as anything other than
> [email-masked], then it is simply broken to pieces.

Try adding multiple passwd(4) entries for the same UID but with
different names (for which there aren't other passwd(4) entries).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 Jan 2014 12:39:46 -0600

> If not, then I don't see a reason to open up this possibility, since existing clients expect otherwise.

With traditional Unix name services you can in fact create aliases for
users and groups.

Try it!  Just create two /etc/passwd entries for the same UID, but with
different names.  Then try to chown(1) a file to either of those two
names.  On many systems both names will be accepted, but ls -l will show
only one of those two names for *all* files owned by that UID.

Ditto groups.

This isn't a required feature of Unix nameservices.  POSIX certainly
doesn't require it.  It just happens to work for *some* nameservices
(but not all).

I don't see why we should forbid such aliasing.  How can NFSv4 impose
requirements on filesystems and nameservices?  It can't.  Stop trying.

Nico
--

---

From: "Noveck, David" <[email-masked]>
Date: Fri, 10 Jan 2014 14:24:30 -0500

The question was not about aliases.  It was about case-insensitivity.

If aliases can and do exist, the spec should not try to prohibit them.

If case-insensitivity of name services does not exist, the spec  should not go out of its way to permit them.

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: Friday, January 10, 2014 1:40 PM
To: Noveck, David
Cc: Trond Myklebust; McDonald, Alex; [email-masked]
Subject: Re: [nfsv4] Normalizations in -30 (Re: rfc3530bis -30: Approach to case insensitivity (5.10))

> If not, then I don't see a reason to open up this possibility, since existing clients expect otherwise.

With traditional Unix name services you can in fact create aliases for users and groups.

Try it!  Just create two /etc/passwd entries for the same UID, but with different names.  Then try to chown(1) a file to either of those two names.  On many systems both names will be accepted, but ls -l will show only one of those two names for *all* files owned by that UID.

Ditto groups.

This isn't a required feature of Unix nameservices.  POSIX certainly doesn't require it.  It just happens to work for *some* nameservices (but not all).

I don't see why we should forbid such aliasing.  How can NFSv4 impose requirements on filesystems and nameservices?  It can't.  Stop trying.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 10 Jan 2014 14:32:10 -0500

> (but is not required to) permit aliases for users and groups.

How is this relevant? As long as there is a consistent 1-1 mapping between the UID/GID/SID and a NFSv4 name@domain or groupname@domain, then that’s not a problem.

> …)

The whole _point_ of introducing the NFSv4 name@domain/group name@domain mapping was in order to allow use of user and group names that match on both the client and the server. The user is entitled to expect that the principal name s/he uses to authenticate with matches the same user/owner name on both the client and server.

The scheme is useless if the principal name [email-masked] maps to username 'foo' on the client, and owner ‘bar’ on the server, because then setting an ACE for ‘foo’ won’t work as expected.
If the server unilaterally introduces a notion of case insensitive owner/group names that the client doesn’t have, then we’re also back in the dark ages: ‘foo’ != ‘FOO’ on any of the NFSv4 clients in existence today. Futhermore, that server had better map the principal name “[email-masked]” into some completely different owner (i.e. to ‘bar’ or ‘BAR’)...

> name@DOMAIN strings- on disk.  If you think that is bad, good luck

It doesn’t need to be changed. However the mapping to and from those UIDs, GIDs and SIDs needs to be consistent with the way that the NFSv4 user/group name space works. See above.

> different names (for which there aren't other passwd(4) entries).

That’s not a situation that can cause my files to be shared with the wrong person.

Trond

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 Jan 2014 14:59:39 -0600

> The question was not about aliases.  It was about case-insensitivity.

Case insensitivity is a form of aliasing.

> If case-insensitivity of name services does not exist, the spec  should not go out of its way to permit them.

First, LDAP permits case-insensitivity for attributes.  See RFC4511,
section 4.1.8, caseIgnoreMatch matching rule.

RFC2307 does not specify anything about the 'uid' attribute that holds
user/group names because... that comes from RFC4519, which says:

      ( 0.9.2342.19200300.100.1.1 NAME 'uid'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

The 'cn' attribute is case sensitive (see RFC4519, section 2.3), or at
least it fails to specify an EQUALITY rule and I don't recall what the
default is.  But RFC2307 says that getpwnam() should search by the
'uid' attribute, while getgrnam() should search by the 'cn' attribute.

So, yes, LDAP is by default case-insensitive for user names but not
group names, at least when using a client that adheres to RFC2307 and
a DIT whose schema adheres to RFCs 2307 and 4519.  Of course,
administrators can change this.

Now, are there *any* NFSv4 clients that would notice this?  I
seriously doubt that clients proper ever do.  Applications might, but
by and large apps don't chown(2) then stat(2) to make sure the chown
took; scripts don't either.

Finally, for goodness' sake! it is most decidedly NOT NFSv4's place to
impose requirements on things that are completely external to it, like
name services.  Stop it.  Why is this so difficult to understand?

NFSv4 simply may not impose normalization normalization on filesystems
that exist and don't already match whatever the requirement would be.

NFSv4 simply may not impose case mapping tables on case-insensitive filesystems.

NFSv4 simply may not impose a case-sensitivity requirement on name services.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 Jan 2014 16:12:54 -0600

> took; scripts don't either.

Also, chown(2), stat(2) and friends (POSIX), and GetSecurityInfo() and
friends (Win32 and Win64) don't deal in user/group *names*.  They deal
in UIDs/GIDs (POSIX) or SIDs (Windows).

Apps (including scripts) that chown/chgrp/setfacl/whatever things
don't bother checking that the operation took.  They also don't bother
making sure that getpwuid()/getgrgid() produce the same names as the
app fed to getpwnam()/getgrnam().

Ideally we'd just use SIDs or SID-like IDs on the wire and to hell
with this name@domain business.  The whole name@domain thing has been
nothing but a huge headache for implementations (upcalls to daemons
that do name service lookups in user-land, with resulting complexity
and performance impact) and for the RFC wordsmithing business (see
this thread and many past ones like it).

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 10 Jan 2014 17:24:51 -0500

> this thread and many past ones like it).

SIDs only make sense on Windoze. There are no Windows NFSv4 clients…

Trond

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 Jan 2014 16:49:23 -0600

> SIDs only make sense on Windoze. There are no Windows NFSv4 clients…

Wrong.

SIDs are really ID@DOMAIN-ID.  Once you understand this you see why
that makes sense even for interop with non-Windows
implementations/sites.

Existence proof that you're wrong: ZFS stores ID@<interned domain ID>,
where the namespace of interned domain IDs is scoped to each
filesystem, the interned domain IDs are SID prefixes, and the entity
ID is the last RID of the SID.  But ZFS doesn't care about the length
or form of the SID, really.  The bits of code that deal with name
resolution of names to/from UIDs/GIDs/SIDs is all in user-land; you
could change it to your heart's content so it deals in something other
than SIDs and Windows and Unix name services.  Neither the filesystem
nor the Solaris NFSv4 client and server care one bit whether the IDs
are for Windows users/groups or something else.  They don't care.

Better: Solaris maps SIDs to/from POSIX UIDs/GIDs, and it does it
well.  The mapping is a local-only mapping, so it's not suitable for
use in NFSv4 on the wire.  For NFSv4 ID@DOMAIN or ID@DOMAIN-ID would
be perfect.

And SIDs are variable length arrays of IDs, so as long as you have a
bit of namespace for "groups in Unix domain" and "users in Unix
domain" you're good to go.  Or you could add something like SIDs but
don't call it "SID" and provide a trivial algorithmic mapping to/from
SIDs for Windows interop (RID@domain-SID, for example, is a
reasonable, loss-less string representation of SIDs that is compatible
with UID/GID@domain).

Nico
--

---

From: "Black, David" <[email-masked]>
Date: Fri, 10 Jan 2014 17:55:01 -0500

I think we ought to give Trond credit for his "running code" ;-).

It sounds like correct operation of the Linux NFSv4.0 client depends on
case preservation of user and group, and we know that that client works
correctly with the vast majority of what's out there.

If that's correct, then the approach of basing the 3530bis draft's i18n on
"running code" suggests that appropriate language for the server would be
at least a "SHOULD" for case preservation of user and group with a warning
about possible security problems when that's not done, based on this text
in section 12.1 of the rfc3530bis draft:

   o  Behavior implemented by most existing clients or servers, where
      that behavior is more desirable than any alternative is described
      using "SHOULD", since new implementations need to follow that
      existing practice unless there are strong reasons to do otherwise.

If the client will actually do something wrong (e.g., fail to provide
file access) when "FOO@domain" comes back as "foo@domain" then a "MUST"
for case preservation may be justified.

The original language (in the current -30 draft's section 5.9) requires
case preservation, because changing between upper and lower cases does not
result in a canonically equivalent Unicode character.

Thanks,
--David

> From: nfsv4 [mailto:[email-masked]] On Behalf Of Trond Myklebust
> Sent: Friday, January 10, 2014 5:25 PM
> To: Nico Williams
> SIDs only make sense on Windoze. There are no Windows NFSv4 clients...
> 
> Trond
>

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 Jan 2014 17:43:40 -0600

> correctly with the vast majority of what's out there.

No one has made that assertion.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 10 Jan 2014 18:44:45 -0500

> for case preservation may be justified.

No clients should be trying to interpret the user@domain in order to grant or deny access; that should always be left to the server, for instance by means of the ACCESS operation.

My objections were about user expectations when they edit the ACL on the file, or change the file ownership using client tools. They will expect the server to interpret the new ACL/owner as if the file was residing on local storage. That means respecting the fact that usernames are case sensitive on UNIX clients, and that my /etc/passwd file may contain entries of the form

foo:x:100:100:foo account:/home/foo:/bin/bash
FOO:x:101:100:FOO account:/home/FOO:/bin/bash

that are treated as separate owners on the client, and therefore need to be treated as separate owners by the server.

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 10 Jan 2014 18:45:35 -0500

> No one has made that assertion.

I beg to differ.

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 Jan 2014 17:53:42 -0600

> No clients should be trying to interpret the user@domain in order to grant or deny access; that should always be left to the server, for instance by means of the ACCESS operation.

Indeed.

> My objections were about user expectations when they edit the ACL on the file, or change the file ownership using client tools. They will expect the server to interpret the new ACL/owner as if the…

Did you read what I wrote about LDAP?

> that are treated as separate owners on the client, and therefore need to be treated as separate owners by the server.

That's how it should be for the files name service.  Now check out
RFCs 4519 and 2307.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 10 Jan 2014 18:57:55 -0500

> Did you read what I wrote about LDAP?

Yes. It really doesn’t matter whether or not LDAP is case insensitive. I can be using a private /etc/passwd on the client. If the server starts mapping my account name ‘FOO' into ‘foo’ instead of telling me that LDAP won’t allow it to map the name FOO into a separate user, then it has a major bug and security hole.

Just have the damned server return NFS4ERR_BADOWNER, and you’re done. No security hole...

> That's how it should be for the files name service.  Now check out

Those are completely irrelevant to my *NIX client.

Trond

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 Jan 2014 17:58:02 -0600

>> No one has made that assertion.

You did not make that assertion earlier.  If you're making it now then
please be specific w.r.t. the following:

I'm not asking about whether /etc/passwd is case-sensitive.  I'm
asking whether the Linux NFSv4 client (or server) depend on *all*
possible name services being case-sensitive.

I believe that's NOT the case, that nothing in the Linux NFSv4 client
(or server) stack depends on *all* possible name services (nsswitch
plugins) being case-sensitive.

Further, LDAP leaves case-sensitivity to the schema, and the default
LDAP schemata for Unix name services makes usernames case-insensitive.
 Therefore you ought to find running systems where there is a
case-insensitive name service.

Nico
--

---

From: Rick Macklem <[email-masked]>
Date: Fri, 10 Jan 2014 18:58:25 -0500 (EST)

Trond Myklebust wrote:
> No clients should be trying to interpret the user@domain in order to
> grant or deny access; that should always be left to the server, for
> instance by means of the ACCESS operation.
> 
For the most part, I agree. There is the case of the ACE for a write
delegation in an Open reply, where I believe the client can choose to
allow Opens locally within the client if the ACE allows it, without
first doing an Access. (I think most/maybe all servers return a nil ACE,
so I'm not sure if this occurs in practice.)

rick

> My objections were about user expectations when they edit the ACL on
> the file, or change the file ownership using client tools. They will
> expect the server to interpret the new ACL/owner as if the file was
> residing on local storage. That means respecting the fact that
> usernames are case sensitive on UNIX clients, and that my
> /etc/passwd file may contain entries of the form
> 
> that are treated as separate owners on the client, and therefore need
> to be treated as separate owners by the server.
> 
> >>> On Fri, Jan 10, 2014 at 2:59 PM, Nico Williams
> >>> <[email-masked]>
> >> wrote:

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 Jan 2014 18:06:12 -0600

> Just have the damned server return NFS4ERR_BADOWNER, and you’re done. No security hole...

No, it doesn't.  POSIX does not define a global user/group name/ID
namespace.  Under POSIX user/group names/IDs are *local*.  NFSv4
defines a global namespace but no mechanism(s) for mapping between
local POSIX and global NFSv4 namespaces.

Making up for that difference on Unix-like systems requires setting up
some conventions.  There's no inherent security hole in having
case-insensitive usernames in a distributed name service like LDAP.
It's *your* fault if you fail to adhere to your enterprise's
conventions.

> Those are completely irrelevant to my *NIX client.

Emphasis on your "my".  Out in the real world people use name services
other than 'files'.

NFSv4 has absolutely no business demanding that the namespace of
user/group names it uses be case-sensitive.  It already isn't
necessarily true of the domain part of name@domain names, and it
already isn't necessarily true of the name part either (see, again,
LDAP).

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 10 Jan 2014 19:09:31 -0500

> already isn't necessarily true of the name part either (see, again,

Nico, that is a straw man issue.

Nobody cares about the case where both the client and the server use case insensitive LDAP and can canonicalize the user and group names in the same way. That is a non issue.

The important case is that where the client presents a user name or group name that is _NOT_ in a format that the server can store and retrieve unambiguously.

Trond

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 Jan 2014 18:54:41 -0600

> Nico, that is a straw man issue.

No, that's what the proposed text demands.  I'm not knocking down a
straw man I put up so I could knock it down.

> The important case is that where the client presents a user name or group name that is _NOT_ in a format that the server can store and retrieve unambiguously.

I'm not sure what that means.  The client does a SETATTR with some ACL
or owner, or file group.  The server *must* attempt to resolve those
names.  If resolution fails, then the server must return an error.
There CANNOT be a requirement that a subsequent GETATTR MUST return
the same names the client set because that requirement would be
incompatible with actual deployments.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 10 Jan 2014 22:08:49 -0500

On Jan 10, 2014, at 19:06, Nico Williams <[email-masked]> wrote:

> other than 'files’.

Irrelevant.

> already isn't necessarily true of the name part either (see, again,

No! Your _server_ has no damned business changing a name that the client gives it. It doesn’t matter whether you use LDAP or any other scheme to distribute the name@domain, whether or not that LDAP scheme is case sensitive or case insensitive.

The fact that clients _are_ case sensitive means that the server is _NOT_ allowed to make the assumption that it can change the case of the name@domain that was supplied. That’s not a SHOULD. It is a MUST…

Trond

---

From: "Haynes, Tom" <[email-masked]>
Date: Sat, 11 Jan 2014 17:29:00 +0000

On Jan 10, 2014, at 7:08 PM, Trond Myklebust <[email-masked]<mailto:[email-masked]>> wrote:

On Jan 10, 2014, at 19:06, Nico Williams <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Jan 10, 2014 at 5:57 PM, Trond Myklebust <[email-masked]<mailto:[email-masked]>> wrote:

Irrelevant.

I have seen plenty of enterprise level customers using 'files'.

The common scenario for this is a rack sitting at a colo site. They don't want to put
in name servers because space is tight and they believe they do not need them.

And then the admin fails to configure the ID domain correctly and we get the 'nobody'
issue.

---

From: Nico Williams <[email-masked]>
Date: Mon, 13 Jan 2014 16:56:02 -0600

> > Emphasis on your "my".  Out in the real world people use name services

Are we talking about the same things?  Clearly it's got to be possible
to deploy NFSv4 and LDAP -- surely you agree, right?

> No! Your _server_ has no damned business changing a name that the
> client gives it. It doesn’t matter whether you use LDAP or any other
> scheme to distribute the name@domain, whether or not that LDAP scheme
> is case sensitive or case insensitive.

Does *your* server store name@domain on disk?  If not, what does it
store?  If it stores UIDs, then the server is clearly changing the name
from name@domain to whatever UIDs, and if the user's name as returned
later by getpwuid() is different than before, then so be it.

> The fact that clients _are_ case sensitive means that the server is
> _NOT_ allowed to make the assumption that it can change the case of
> the name@domain that was supplied. That’s not a SHOULD. It is a MUST…

You... missed... the point.  Fortunately I see no real harm from the
text I was objecting to -- it's wrong, but it will be ignored by just
about every implementor.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 13 Jan 2014 18:10:27 -0500

> to deploy NFSv4 and LDAP -- surely you agree, right?

I agree that we need to be able to deploy NFSv4 and LDAP. I’m stating that is completely irrelevant to the question of whether or not case insensitivity for user/group names should be supported in the NFSv4 spec.

> later by getpwuid() is different than before, then so be it.

Why would my server do that if it checked what getpwuid() returns when I set the ACL/owner/groupname/… before deciding whether or not to return NFS4ERR_BADOWNER?

> You... missed... the point.

What point? That I’m storing uids? No, I didn’t miss that point… The text in RFC3530bis-27 reads:

"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 (for which see below) when a corresponding GETATTR is done."

There is no mention there of how you store the information, only how you _return_ it in response to a GETATTR request.

Unless your version of getpwuid() is returning random case names and groups (which would be quite a novelty, even for LDAP), then it is perfectly possible to predict at storage time what GETATTR will return.

>  Fortunately I see no real harm from the

Why?

Trond

---

From: Nico Williams <[email-masked]>
Date: Mon, 13 Jan 2014 17:29:09 -0600

On Mon, Jan 13, 2014 at 06:10:27PM -0500, Trond Myklebust wrote:
> Why would my server do that if it checked what getpwuid() returns when
> I set the ACL/owner/groupname/… before deciding whether or not to
> return NFS4ERR_BADOWNER?

First, there's no reason that getpw*() couldn't support aliases, and, in
fact, in practice they do, therefore it seems silly to check that
getpwuid(getpwnam()) returns the same user information.

Second, does your server actually do that getpwuid(getpwnam())?  Why?

Third, if the client does the canonicalization on its side the usernames
can still be case-insensitive and who bloody cares what NFSv4 says.

But really, it's none of NFSv4's business if some domain wants their
usernames to be case-insensitive (and in LDAP, using RFC2307, they would
be).

> "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 (for which see b…

That forbids user name changes.  It also forbids the use of aliases.  Is
that the intention of the WG?  If so, I think that needs a) more
explicit text, b) justification.

> Unless your version of getpwuid() is returning random case names and
> groups (which would be quite a novelty, even for LDAP), then it is
> perfectly possible to predict at storage time what GETATTR will
> return.

See above.

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 13 Jan 2014 18:48:27 -0500

> Second, does your server actually do that getpwuid(getpwnam())?  Why?

Please see the entire thread so far… Dealing with ACLs, owners and groups in an environment that MAY be case sensitive is why. If there are LDAP aliases, then the client can just as easily do getpwuid(getpwnam()) in order to canonicalise. In fact, most *NIX clients don’t need to: they deal in uids and gids at the kernel level, and use getpwuid() directly in order to convert that into a name@domain form.

What the client cannot do, is second guess that the server is doing the wrong thing, if the latter just silently accepts to store an acl for FOO@domain as foo@domain.

---

From: Nico Williams <[email-masked]>
Date: Mon, 13 Jan 2014 18:10:17 -0600

On Mon, Jan 13, 2014 at 06:48:27PM -0500, Trond Myklebust wrote:
> Please see the entire thread so far… Dealing with ACLs, owners and

Does your server check that name@domain's in SETATTRs are canonical?
Are servers required to?  I did not get that from the text in question
(see below).

> groups in an environment that MAY be case sensitive is why. If there
> are LDAP aliases, then the client can just as easily do
> getpwuid(getpwnam()) in order to canonicalise. In fact, most *NIX
> clients don’t need to: they deal in uids and gids at the kernel level,
> and use getpwuid() directly in order to convert that into a
> name@domain form.

Right, indeed, clients kinda get there by default on Unix and Unix-like
systems.

But if one were to build a user-land client for doing things that a
kernel client can't (e.g., refer to arbitrary name@domain's)... then it
becomes important for that client to canonicalize names, or, at any
rate, for the user to (since if the client doesn't see to it and server
implements the getpwuid(getpwnam()) check then the client's SETATTRs may
fail).

> What the client cannot do, is second guess that the server is doing
> the wrong thing, if the latter just silently accepts to store an acl
> for FOO@domain as foo@domain.

What's wrong with that if foo@domain is FOO@domain's canonical name /
FOO@domain is an alias of foo@domain?

Presumably if the client and server understand that domain's conventions
then it's OK to use aliases, and if they don't share the same
conventions, well, then there was never anything that the server could
have done to make things better.

Lacking a protocol/conventions for federating the NFSv4 user/group
namespace we're stuck with either a) all clients/servers in one (or
perhaps more) domains knowing all there is to know about that(those)
domain(s) and name resolution in them, or b) Active Directory (i.e., a
set of protocols/conventions for federating the various namespaces).

This is what draft-adamson-nfsv4-multi-domain is partly about,
incidentally.

> >> "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 (for which see
> >> below) when a corresponding GETATTR is done."
> > 
> > That forbids user name changes.  It also forbids the use of aliases.
> > Is that the intention of the WG?  If so, I think that needs a) more

Can I get an answer to this?  Is it really the intention that there is
no time limit to how much later a subsequent GETATTR must return the
same data?

I mean, as written the text doesn't even allow subsequent ownership
changes.  Surely that is an absurd reading of the text.  Yet, it is
valid a literal reading of the text.

But just as one should not derive an "owernship can't change" rule from
that text I'd also not have derived a "servers must reject name@domain's
that aren't canonical" that you seem to derive from it.  The text in
question is a bit too malleable and, at any rate, strange to me.  I
suspect the original intention of that and surrounding text was just to
deal with I18N and the whole one-domain thing (see Tom's response in
this thread).

I'd propose clearer text but now I'm completely unsure as to the
*actual* intended meaning, which is why I'm asking these questions.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 13 Jan 2014 19:45:29 -0500

> Does your server check that name@domain's in SETATTRs are canonical?

It doesn’t appear to do so now, but afaics it should, since it is storing uids and gids.

> implements the getpwuid(getpwnam()) check then the client's SETATTRs may

Are we talking hypothetical clients? If so, then may I suggest they store their data on a hypothetical server that stores name@domain rather than uids and gids?

> FOO@domain is an alias of foo@domain?

Why isn’t the client figuring that out, and if it isn’t, then how is the above correct?

> have done to make things better.

It could check for equality.

> that aren't canonical" that you seem to derive from it.

I’m not saying that the server must reject a name@domain that isn’t in canonical form. I’m saying that it must reject a name@domain that it won’t be able to return verbatim in a later GETATTR call.

If it stores those name@domain as uids or gids that can have name aliases, then it needs to ensure somehow that it returns the alias that the client sent it.

> The text in

---

From: "Noveck, David" <[email-masked]>
Date: Tue, 14 Jan 2014 11:12:41 -0500

Let me make a few points about this discussion:

*         There's been a lot of discussion of potential case-insensitivity, but many of the examples about behavior to be allowed or disallowed does not concern case-insensitivity per se, but rather non-case-preserving behavior.

*         The text that we are talking about (regarding what GETATTR would/should/might return) prohibits non-case-preserving behavior and allows normalization (either NFC or NFD).

*         It does not seem to be the intention of this text to prohibit aliases, as normally understood.  For those with a broader understanding of the concept of "alias", let me state that I don't consider the following as aliasing in this context:

a)      Getting "foo" and returning "FOO" or "Foo"

b)      Getting ANGSTROM-SYMBOL and returning LATIN-LETTER-CAPITAL-A-WITH-RING-ABOVE  (NFC form) or LATIN-LETTER-CAPITAL-A followed by COMBINING-RING-ABOVE (NFD  form)

Despite the fact that the current spec allows b) and doesn't allow a), these two form of name variability are both not considered aliasing.

*         The fact that a subsequent SETATTR can change what GETATTR returns, is a drafting error which could be easily dealt once  the  case issue is dispensed with.  Mea culpa.

-----Original Message-----
From: nfsv4 [mailto:[email-masked]] On Behalf Of Trond Myklebust
Sent: Monday, January 13, 2014 6:48 PM
To: Nico Williams
Cc: [email-masked]
Subject: Re: [nfsv4] Normalizations in -30 (Re: rfc3530bis -30: Approach to case insensitivity (5.10))

>> On Jan 13, 2014, at 17:56, Nico Williams <[email-masked]<mailto:[email-masked]>> wrote:

>>> store?  If it stores UIDs, then the server is clearly changing the

>>> name from name@domain to whatever UIDs, and if the user's name as

>>> returned later by getpwuid() is different than before, then so be it.

>> Why would my server do that if it checked what getpwuid() returns

>> when I set the ACL/owner/groupname/... before deciding whether or not

>> to return NFS4ERR_BADOWNER?

> First, there's no reason that getpw*() couldn't support aliases, and,

> in fact, in practice they do, therefore it seems silly to check that

> Second, does your server actually do that getpwuid(getpwnam())?  Why?

Please see the entire thread so far... Dealing with ACLs, owners and groups in an environment that MAY be case sensitive is why. If there are LDAP aliases, then the client can just as easily do getpwuid(getpwnam()) in order to canonicalise. In fact, most *NIX clients don't need to: they deal in uids and gids at the kernel level, and use getpwuid() directly in order to convert that into a name@domain form.

> Third, if the client does the canonicalization on its side the

> usernames can still be case-insensitive and who bloody cares what NFSv4 says.

> usernames to be case-insensitive (and in LDAP, using RFC2307, they

> would be).

>>>> the name@domain that was supplied. That's not a SHOULD. It is a

>>>> MUST...

>> What point? That I'm storing uids? No, I didn't miss that point... The text in RFC3530bis-27 reads:

nfsv4 mailing list

[email-masked]<mailto:[email-masked]>

---

From: Nico Williams <[email-masked]>
Date: Tue, 14 Jan 2014 10:38:48 -0600

> It doesn’t appear to do so now, but afaics it should, since it is

I argue against the "should".  I don't think any server does this now
(and all servers, at least all general purpose OS ones, and probably all
of them perios, store UIDs/GIDs/SIDs/similar-but-not-names).

> > kernel client can't (e.g., refer to arbitrary name@domain's)... then
> > it becomes important for that client to canonicalize names, or, at
> > any rate, for the user to (since if the client doesn't see to it and
> > server implements the getpwuid(getpwnam()) check then the client's
> > SETATTRs may fail).
> 
> Are we talking hypothetical clients? If so, then may I suggest they
> store their data on a hypothetical server that stores name@domain
> rather than uids and gids?

We're talking about a hypothetical client whose purpose is to allow
users on an otherwise single-domain-capable *nix-like client to
nonetheless be able to view and manipulate ACLs on multi-domain-capable
servers.  It's quite feasible; user-land NFSv4 client implementations
have existed AFAICR.

So I'm asking you if the text we're arguing over imposes a requirement
on such clients (or *any* clients) to send canonical user/group names.

To my reading it implies it.  This is too important a point to merely
imply though.

> Why isn’t the client figuring that out, and if it isn’t, then how is

Why should it?  But *if* that's what the WG wants the client to do, then
the RFC ought to be clear on that point, and currently it's not.

> It could check for equality.

How?  Remember, COMPOUND is not atomic, so merely sending a SETATTR and
GETATTR to check that the ACL after being set == the ACL set by the
client is out.  And how would the client recover from noticing that the
server didn't do what the client had wanted anyways?

(Of course, the text as written doesn't even allow for the passage of
time and other changes to the file's attributes, and so on as I've
pointed out.)

> I’m not saying that the server must reject a name@domain that isn’t in
> canonical form. I’m saying that it must reject a name@domain that it
> won’t be able to return verbatim in a later GETATTR call.

For any server that stores UIDs/GIDs/SIDs/similar-not-name-form the
latter is equivalent to the former.  That's pretty much every server.

Now your server doesn't do this canonicalization, and I suspect no
server does.  We have text that doesn't reflect reality.

> If it stores those name@domain as uids or gids that can have name
> aliases, then it needs to ensure somehow that it returns the alias
> that the client sent it.

That is feasible if the client sends a GETATTR in the same compound, but
the text doesn't address when the GETATTR might occur.  Otherwise what
you're saying is utterly infeasible -- even with a cache, it'd have to
be a per-client cache, and given the lack of attention to the passage of
time in that text, it'd have to be a persistent cache.

I suspect that text is there only by accident, not because what you say
you want is the WG's consensus.  You're happy with [some of] the text's
implications, and I'm not.  But much more interesting than our
disagreement is what the WG had/has consensus for here.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 14 Jan 2014 11:18:47 -0600

On Tue, Jan 14, 2014 at 11:12:41AM -0500, Noveck, David wrote:
> * There's been a lot of discussion of potential case-insensitivity,
>   but many of the examples about behavior to be allowed or disallowed
>   does not concern case-insensitivity per se, but rather
>   non-case-preserving behavior.

Even this is bad because servers don't store name@domain.  They store
UIDs, GIDs, and/or SIDs (or similar numeric/non-name forms).  Such
servers (pretty much all servers) therefore cannot preserve case because
they cannot preserve the name@domain strings sent by the clients.

I suspect there was never a conscious decision to require that servers
store/cache name@domain forms, nor that they check for and reject
non-canonical name@domain forms sent by clients.

> * The text that we are talking about (regarding what GETATTR
>   would/should/might return) prohibits non-case-preserving behavior
>   and allows normalization (either NFC or NFD).

That prohibition is bad.  Please remove it.  See above, below, and this
whole thread.

> * It does not seem to be the intention of this text to prohibit
>   aliases, as normally understood.  For those with a broader
>   understanding of the concept of "alias", let me state that I don't
>   consider the following as aliasing in this context:

Yet it does that for any server that doesn't store name@domain forms.

> * The fact that a subsequent SETATTR can change what GETATTR returns,
>   is a drafting error which could be easily dealt once  the  case
>   issue is dispensed with.  Mea culpa.

That problem surely can get fixed -- no one would agree that attributes
cannot be changed once set (except in the context of an immutability
attribute, but I digress).

That leaves the implication that any server that stores UIDs/GIDs/SIDs
must then check that names sent by clients are canonical and reject them
otherwise.  That should be stated explicitly, or, much better IMO,
neither stated nor implied (which then means doing away with any text
about case w.r.t.  name@domain).

The case preservation requirement is neither reflective of actual
implementations nor desirable.  To the first point, for example, Trond
admits his server doesn't check that user/group names sent to it are
canonical, and I strongly suspect no server does because it'd be an
utter waste of its resources to do so.  To the second point, evidence of
the non-implementation of that requirement is strongly suggestive that
the requirement is not desirable, and the fact that it'd be a waste of
resources and it'd be surprising to some clients (granted, so far
hypothetical clients, to my knowledge) adds to the argument.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 14 Jan 2014 13:38:03 -0500

> of them perios, store UIDs/GIDs/SIDs/similar-but-not-names).

Those same servers are probably using getgrnam() in order to convert the groups into gids. On Linux, at least, that function is going to be case sensitive, even with LDAP and NIS backing it.
They are using getpwnam() to convert the usernames into uids, Again, that will be case sensitive with something like NIS, and possibly case insensitive if LDAP is backing it.

Now imagine if the clients are using NIS and/or local /etc/passwd, and the server is using LDAP (and yes, I assert that that kind of environment does exist). How should the server deal with a request to store an ACL for FOO@domain?

> on such clients (or *any* clients) to send canonical user/group names.

It needs to send a user/group name that the server can store. If all the server can store and retrieve is canonical user/group names (because it converts the username/group into a uid/gid or a sid), then yes, the client needs to send a canonical form. This is no different from requiring a client that has several local aliases for the same uid to send a username that the server understands and can store.

> server didn't do what the client had wanted anyways?

I mean that the _server_ can check for string equality between what the client sends, and what it is prepared to return in GETATTR. I completely agree that COMPOUND non-atomicity means that the client is unable to check the server up on this. This is precisely why it is a problem that the NFSv4 protocol needs to deal with.

> disagreement is what the WG had/has consensus for here.

The alternatives have a security problem to deal with due to the existence of case sensitive clients. Just crying “case-insensitive LDAP" isn’t sufficient, unless you make it mandatory to use (which would be a problem in itself).

Trond

---

From: Nico Williams <[email-masked]>
Date: Tue, 14 Jan 2014 13:07:17 -0600

On Tue, Jan 14, 2014 at 01:38:03PM -0500, Trond Myklebust wrote:
> Those same servers are probably using getgrnam() in order to convert
> the groups into gids. On Linux, at least, that function is going to be
> case sensitive, even with LDAP and NIS backing it.  They are using

Not buying it.  If the name service is LDAP and LDAP chooses to be
case-insensitive (because of the schema in use) then there's not much
the LDAP client can do to force case-sensitivity (well, besides always
folding case, but that would mean losing case-preservation whereas the
point of the text I'm objecting to is case-preservation).

Think about it.

> getpwnam() to convert the usernames into uids, Again, that will be
> case sensitive with something like NIS, and possibly case insensitive
> if LDAP is backing it.

> It needs to send a user/group name that the server can store. If all
> the server can store and retrieve is canonical user/group names
> (because it converts the username/group into a uid/gid or a sid), then
> yes, the client needs to send a canonical form. This is no different

If the client sends an alias and getpwnam() succeeds and the server
stores a UID, why on earth would that mean the client should have sent a
canonical name and that the server should punish it for not doing so?

Think about it.

> from requiring a client that has several local aliases for the same
> uid to send a username that the server understands and can store.

Since the server stores UIDs/GIDs/SIDs all that matters is that the
client and server have the same name service configuration.  It does NOT
matter if the name service is case-insensitive.

IF the servers stores name@domain then the server will want to either
canonicalize and store canonical names, or canonicalize at access
control evaluation time.  I still see no need for the client to send
canonical names.

> I mean that the _server_ can check for string equality between what
> the client sends, and what it is prepared to return in GETATTR. I
> completely agree that COMPOUND non-atomicity means that the client is
> unable to check the server up on this. This is precisely why it is a
> problem that the NFSv4 protocol needs to deal with.

But the text is making a guarantee to the client.  One the server can't
meet because of the non-atomicity of COMPOUND and so on.

At the very least the text is wrong, regardless of how your disagreement
with me shakes out.

> The alternatives have a security problem to deal with due to the
> existence of case sensitive clients. Just crying “case-insensitive
> LDAP" isn’t sufficient, unless you make it mandatory to use (which
> would be a problem in itself).

Nonsense.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 14 Jan 2014 13:47:52 -0600

Let me try tackling this from a different end.

Clients today generally send [what they think are] canonical user/group
names on the wire.  This is a result of using internal IDs (UIDs, GIDs,
SIDs) in the middle of the stack (from the system calls down through the
VFS to the NFSv4 client module): the client is forced to lookup names by
ID, and this lookup can generally be expected to produce canonical
names.

I'm OK with saying that clients SHOULD (maybe even MUST) send canonical
user/group names.  Since clients generally already do... this would not
be a big deal.

I'm against saying that servers SHOULD (much less MUST) reject non-
canonical names sent by clients, since in practice that means doing
extra, useless work on the server side.  There's no value in this.

I'm also against saying that servers SHOULD (much less MUST) "return"
the same user/group names as sent by the client.  If a client fails to
send canonical names, too bad for it.  At the very least the whole use
of "return" must be elaborated on.

Finally, I'm *very* much against saying or implying that name services
used by servers MUST NOT (or even SHOULD NOT) be case-insensitive.

I'm somewhat less uncomfortable with a recommendation that name services
be case-preserving, that if LDAP is case-insensitive for usernames then
getpwnam("fOO") should return "fOO" as foo's username, not "Foo" or some
other form.  It's possible that POSIX already requires that (I should
check), but then, the whole world isn't POSIX.

The problem I have here is that it is decidedly NOT NFSv4's place to
dictate requirements for external things (e.g., LDAP, FAT32, NTFS, HFS+,
ZFS, ...) that NFSv4 implementations do/will depend on that have existed
outside of NFSv4 and which cannot be changed or deprecated on NFSv4's
whims.  We've effectively accepted this w.r.t. filesystems already, now
all we have to do is accept it w.r.t. name services :)

Nico
--