Subject: [nfsv4] Representing Windows special identities across NFSv4

From: Jordan Brown <[email-masked]>
Date: Mon, 20 Jun 2011 10:08:49 -0700

In trying to integrate our Windows / SMB support with our NFSv4 support, we 
have encountered problems with the handling of Windows special identities.

Background:  Windows defines a number of identities with more-or-less 
special semantics.  These identities can appear in file metadata - in 
particular, in ACLs but probably also in ownership.  A reasonably complete 
list, as of some time, can be found at
http://msdn.microsoft.com/en-us/library/cc980032%28PROT.10%29.aspx

The question at hand is how to represent these identities as names in 
NFSv4.  Ideally there would be a standard, so that different implementers 
could exchange file metadata and reconstruct the original identities.  For 
extra credit, such a standard would specify interoperable behavior for 
special identities that have not yet been introduced, so that they could be 
carried transparently across NFSv4.

The "ACE who" section of the NFSv4 RFC lists a handful of similar 
identities, using a name@ syntax, but does not cover even today's list of 
Windows special identities.  (Side note:  the "ACE who" section, and in 
particular this list of special names, should probably be merged with the 
"Interpreting owner and owner_group" section, so that they define a common 
namespace.  While some of the special names are meaningful only in an ACL 
context, if a file is created by an anonymous client who else would own it 
but ANONYMOUS@?)

Is there any established practice in this area?

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 20 Jun 2011 12:43:44 -0500

On Jun 20, 2011, at 12:08 PM, Jordan Brown wrote:

> In trying to integrate our Windows / SMB support with our NFSv4 support, we have encountered problems with the handling of Windows special identities.
> 
> Background:  Windows defines a number of identities with more-or-less special semantics.  These identities can appear in file metadata - in particular, in ACLs but probably also in ownership.  A reasonably complete list, as of some time, can be found at
> The question at hand is how to represent these identities as names in NFSv4.  Ideally there would be a standard, so that different implementers could exchange file metadata and reconstruct the original identities.  For extra credit, such a standard would specify interoperable behavior for special identities that have not yet been introduced, so that they could be carried transparently across NFSv4.
> 
> The "ACE who" section of the NFSv4 RFC lists a handful of similar identities, using a name@ syntax, but does not cover even today's list of Windows special identities.  (Side note:  the "ACE who" section, and in particular this list of special names, should probably be merged with the "Interpreting owner and owner_group" section, so that they define a common namespace.  While some of the special names are meaningful only in an ACL context, if a file is created by an anonymous client who else would own it but ANONYMOUS@?)
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

Andy Adamson is working on "NFSv4 Multi-Domain Access" (see
http://tools.ietf.org/html/draft-adamson-nfsv4-multi-domain-access-04 )
and it ties into what you want.

I know I heard him talking about SIDS a couple of weeks ago (over a
beer, so not in the archives).

He is on vacation, but I am sure once he returns, he can address this issue.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 20 Jun 2011 13:46:26 -0400

On Mon, Jun 20, 2011 at 10:08:49AM -0700, Jordan Brown wrote:
> In trying to integrate our Windows / SMB support with our NFSv4
> support, we have encountered problems with the handling of Windows
> special identities.
> 
> Background:  Windows defines a number of identities with
> more-or-less special semantics.  These identities can appear in file
> metadata - in particular, in ACLs but probably also in ownership.  A
> reasonably complete list, as of some time, can be found at
> The question at hand is how to represent these identities as names
> in NFSv4.  Ideally there would be a standard, so that different
> implementers could exchange file metadata and reconstruct the
> original identities.  For extra credit, such a standard would
> specify interoperable behavior for special identities that have not
> yet been introduced, so that they could be carried transparently
> across NFSv4.
> 
> identities, using a name@ syntax, but does not cover even today's
> list of Windows special identities.  (Side note:  the "ACE who"
> section, and in particular this list of special names, should
> probably be merged with the "Interpreting owner and owner_group"
> section, so that they define a common namespace.  While some of the
> special names are meaningful only in an ACL context, if a file is
> created by an anonymous client who else would own it but
> ANONYMOUS@?)
> 

The Linux server just doesn't deal with anything other than GROUP@,
OWNER@, and EVERYONE@, because I've never understood what to do with the
others....

--b.

---

From: Nico Williams <[email-masked]>
Date: Mon, 20 Jun 2011 12:51:30 -0500

> and it ties into what you want.

That I-D doesn't address Jordan's issue.

There are several possible things to do here.  One is to add new
special who values for the missing special SIDs.  (All special RIDs
relative to domain SIDs can be represented today without any
additions.)  This will only work for clients and servers that know
about the new who values.

Another is to add negotiation of the use of stringified SIDs on the
wire.  This will only work for implementations that implement that
option.

There are other hackier options.  None that I can think of will just work.

Long-term I much, much prefer the stringified SID idea as that greatly
reduces the amount of work that the client and/or server must do when
one, the other, or both natively deal in SIDs.  Using name@domain is a
terrible waste of resources.  Granted, this requires viewing SIDs as
something other than specific to one operating system, but guess what:
that's actually the case nowadays.

Nico
--

---

From: Jordan Brown <[email-masked]>
Date: Mon, 20 Jun 2011 11:22:01 -0700

> about the new who values.

Yes, including having the same problem the next time that MS (or anybody 
else) introduces new special SIDs.

> that's actually the case nowadays.

One possible general approach is to recognize that there are some number of 
"internal" representations that may not be mappable to generic name@domain 
representations, and provide some way of tagging those names to avoid 
collision.  There's some existing legacy support for POSIX UID/GID along 
those lines, but without any tagging.  Parties could use those 
representations through negotiation, or could just use them without 
negotiation if there are no alternatives.

---

From: Nico Williams <[email-masked]>
Date: Mon, 20 Jun 2011 13:59:56 -0500

> else) introduces new special SIDs.

Also, all special SIDs that are not domain-relative generally have
special semantics that servers must understand.

> negotiation if there are no alternatives.

We could certainly tag some ACEs such that peers know to ignore them
if they can't understand them, but this would create a number of
knock-on problems.  For example, if it's the client that doesn't
understand some ACE, how to present it to local applications?  And how
to preserve it when an application edits the ACL containing that ACE?
Similarly, if the server doesn't understand it but the *user* that set
it expected the server to understand the special semantics of that ACE
-> problem.

The simplest negotiation is to try setting some ACE and see what
happens.  If the server rejects it, then it's because it didn't
understand that ACE.

However, for domain-relative SIDs, *particularly* host-relative SIDs,
it'd be quite useful to use a stringified SID representation on the
wire.  There exist applications that set ACLs on what they expect to
be local files but which are in fact not.  Such applications insist on
being able to set ACEs with local subjects as ACE who values, and they
break if the server rejects such ACEs.

Nico
--

---

From: Jordan Brown <[email-masked]>
Date: Mon, 20 Jun 2011 12:58:07 -0700

> special semantics that servers must understand.

I don't know if I'd use the word "must" there.  If a server doesn't 
understand the semantics of a particular SID, I'd probably prefer that it 
blindly stored and mostly ignored the SID, than that it reject the request. 
  That seems like the right form of graceful degradation.

> knock-on problems.

First, I don't think the problem is limited to ACEs.  I'd consider it to 
apply to all names - in particular, ACEs and owners.

I thought about giving a suggested implementation, but thought better of 
it.  Perhaps I should, to give an idea what I'm thinking of.

Allow a domain owner (e.g. Oracle for oracle.com, Microsoft for 
microsoft.com, the NFSv4 WG for nfsv4.org) to define special names inside 
their domain.  Those that wish to support a particular set of special names 
could do so.  Thus, for instance, MS could define that 
[email-masked] represents a raw SID.  NFSv4 could define that 
<n>@user.posix.nfsv4.org represents a POSIX UID.

Such a scheme would allow the creation of any number of such specialized 
proprietary namespaces, without the risk that they will collide with one 
another, with standard names, or with standards-defined names.

> For example, if it's the client that doesn't

For both of these, the answer is the same as it is for any other name that 
the client doesn't know how to resolve.  Probably an error, but in theory a 
client that was able to carry the string form all the way to the user could 
blindly carry it.

> it expected the server to understand the special semantics of that ACE

See above about graceful degradation.

> happens.  If the server rejects it, then it's because it didn't

I wouldn't want a server to reject an ACE for, say, S-1-5-9 Enterprise 
Domain Controllers just because it doesn't know what that means.  I'd want 
it to blindly store and retrieve the SID, somehow.

> break if the server rejects such ACEs.

Yes... and there are also applications (as I know you know, but this is for 
a wider audience) that expect to be able to construct SIDs using their own 
rules for their own purposes, and have the file system store and retrieve 
those SIDs.

---

From: Nico Williams <[email-masked]>
Date: Mon, 20 Jun 2011 15:25:03 -0500

>  That seems like the right form of graceful degradation.

If the user that set the ACE expected the server to enforce whatever
that ACE's semantics were, then we have a criticality issue: it's
critical for the user to know whether their expectations will be met,
particularly if the ACE is a DENY ACE!   (I'd be happy to say that
DENY ACEs are not allowed, or even recommended against, for groups nor
for any subjects other than users.  But there are some SIDs that are
critical even in ALLOW ACEs; see below.)

> apply to all names - in particular, ACEs and owners.

Indeed, this applies to all of what MSFT calls "security descriptors".
 It's kinda unfortunate that in the Unix / NFS world we still think of
"owner" and "ACL" and "mode" as distinct things -- they are tightly
connected, and should be thought of as a unit for security purposes.

> I thought about giving a suggested implementation, but thought better of it.
>  Perhaps I should, to give an idea what I'm thinking of.
>

No need to go that far.  Just ask MSFT to setup an IANA registry for
SID authority values and dole those out (there's 2^48 of them).

Regardless of how you might create a namespace for special subjects,
it's important to have a method by which to signal criticality.
Alternatively disallow or discourage the use of such SIDs in DENY
ACEs.

> client that was able to carry the string form all the way to the user could

The point was that using names on the wire doesn't really simplify
anything.  It only complicates things.

> See above about graceful degradation.

That only addresses special SIDs, and only partially.

> it to blindly store and retrieve the SID, somehow.

Right.  What about Creator Owner (S-1-3-0)?  What about Owner Rights
(S-1-3-4)?  These two and a handful of others have semantics that the
server must understand even when the ACE is an ALLOW ACE.  Probably
the best thing to do is to close the set of such special subjects and
declare that all other special subjects are only critical when used in
DENY ACEs.

>>[...]

This is relevant to the NFSv4 WG because so many server implementors
also implement other protocols for accessing the same filesystems
concurrently, thus if clients can create ACLs with one protocol that
cannot be represented in NFSv4 that creates a real interop problem.
Yes, the WG could rule that out of scope for this WG, but since so
many of its participants ought to want to do something about this
interop problem, chances are the WG will consider them to be in scope.

Nico
--

---

From: Olga Kornievskaia <[email-masked]>
Date: Mon, 20 Jun 2011 18:04:18 -0400

On Mon, Jun 20, 2011 at 1:08 PM, Jordan Brown <[email-masked]> wrote:
> The question at hand is how to represent these identities as names in NFSv4.
>  Ideally there would be a standard, so that different implementers could
> exchange file metadata and reconstruct the original identities.  For extra
> credit, such a standard would specify interoperable behavior for special
> identities that have not yet been introduced, so that they could be carried
> transparently across NFSv4.
>

What prevents you from mapping windows special sids to nfs4 names in
your client software via something like ldap or windows active
directory and then doing the reverse on the server-side?

As Bruce pointed out that linux implementation only respects the 3 he
listed, so if you send it ANONYMOUS@, the server will fail your
request with a bad_name error. I'm not sure if other NFS4 servers
implement all 10 special "who" fields. As a client implementor it
seems easier to assume that the server will not support anything
besides the first three ( and then rely on mapping other identities
like any other user/group identities (via ldap or whatever mapping
mechanism one might use).

If one wanted to just include a pure sid as their "nfs4user" part of
the nfs4user@nfs4domain part, I don't see why they can't do it now. A
server would need to be happy mapping it but again that's server-side
implementation issue.

---

From: Nico Williams <[email-masked]>
Date: Mon, 20 Jun 2011 17:19:40 -0500

> directory and then doing the reverse on the server-side?

a) Not all well-known SIDs are resolvable through AD (LDAP or LSA RPC,
as opposed to the LSA API).

b) Some well-known SIDs have special semantics that the server has to
understand.

Now add the multi-protocol file server wrinkle.  Something has to be done.

At least, IIRC, no new well-known SIDs with critical semantics have
been added since Windows 2000.  And then when MSFT did add some they
back-patched all the way to NT 3.51.  I take this as evidence that
MSFT will likely avoid adding new such well-known SIDs, though they
might add new non-critical well-known SIDs -- a statement from MSFT to
that effect would be better though.

Nico
--

---

From: Jordan Brown <[email-masked]>
Date: Mon, 20 Jun 2011 16:06:50 -0700

Some scope reset may be in order.

I don't have the option of making changes to the protocol per se or to the 
file systems.  I can tweak how names are interpreted.

I have a file that has Windows special identifiers as part of its metadata. 
  My server gets a request to retrieve the file's metadata.  How do I 
report those identifiers?  Plus, of course, the flip sides:  what forms 
does my server accept?  Plus the same for my clients.  Rejecting requests 
is a non-starter in most or all cases.

If the NFSv4 WG has no particular opinion on that question, I'll go ahead 
and design something Solaris-specific and so Solaris systems will 
interoperate. Non-Solaris systems will see identifiers that they don't 
understand and that probably won't be any worse than anything else I might do.

---

From: Nico Williams <[email-masked]>
Date: Mon, 20 Jun 2011 18:25:31 -0500

> file systems.  I can tweak how names are interpreted.

You have influence.  First because you can talk to the team that owns
Solaris' NFSv4 stack, second because you can convince the NFSv4 WG
that something has to be done in the protocol, if, indeed, something
does have to be done in the protocol.

To say "I only own name services, thus I'm only going to focus on
things I can do there" would be a bit short-sighed, IMO.  Of course,
here you are, so you've clearly decided to use your influence...
Don't shrink so soon!  :)

>  My server gets a request to retrieve the file's metadata.  How do I report
> those identifiers?  Plus, of course, the flip sides:  what forms does my
> server accept?  Plus the same for my clients.  Rejecting requests is a
> non-starter in most or all cases.

Solution #1: make up a local user/group naming convention for special
SIDs, document such names that match your convention as reserved to
the operating system, publish your naming convention, and hope it
takes root.

Solution #2: get the NFSv4 WG to add special ACE who values.

Solution #3: squat on new special ACE who values and tell the NFSv4
WG.  For full effect wait until after you ship before telling the WG,
of course.

Solution #4: return an error to the client.

Solution #5: like #1, but with user-configurable names.

Solution #6: filter out those ACEs on GETATTR.

Solution #7: filter out those ACEs on GETATTR and try to figure out
how to add them back in when the client sets the ACL.

To me only (2), (4) and (5) are acceptable.  But if you do (1) or (3)
I suspect it won't be the end of the world.  Some folks might settle
for (6) as well, though I don't like it.

> understand and that probably won't be any worse than anything else I might

So... something like (1)?

Incidentally, while Solaris (and Linux, ...) reserves some UIDs and
GIDs for system purposes, there's no reserved user/group _name_
namespace.  It might be nice to fix that some day...

Nico
--

---

From: Jordan Brown <[email-masked]>
Date: Mon, 20 Jun 2011 17:07:14 -0700

> the operating system, publish your naming convention, and hope it

Yes, that's the most likely answer if I DIY.

It would probably be names with no atsigns that look like 
"S-xxx-yyy-zzz..." - basically, the obvious extension of the existing "bare 
UID/GID" convention.

> Solution #2: get the NFSv4 WG to add special ACE who values.

Doesn't expand to address SIDs that we don't know about.

> WG.  For full effect wait until after you ship before telling the WG,

:-)

> Solution #4: return an error to the client.

That's essentially what we do now.  I think we've already got customer 
complaints.

> Solution #5: like #1, but with user-configurable names.

I'm not going to introduce that kind of complexity.  Besides, it doesn't 
work for identifiers that are invented by applications.

> Solution #6: filter out those ACEs on GETATTR.

Silently dropping ACEs seems like a Really Bad Idea.

Also, remember the mantra:  It's Not Just ACEs.

> how to add them back in when the client sets the ACL.

I don't believe in trying to do unpredictable things like that.  If a user 
says "set the ACL to <this>", I want to set it to <this>, period.

> So... something like (1)?

Most likely.

Second most likely (but unlikely) is [email-masked].

> namespace.  It might be nice to fix that some day...

Yes.  Whether it's fixable isn't clear to me, but I figure that (for 
instance) probably at least one user somewhere in the world got hosed when 
we grabbed the name "gdm".

But that's Not This Problem.

---

From: Nico Williams <[email-masked]>
Date: Mon, 20 Jun 2011 20:05:08 -0500

On Mon, Jun 20, 2011 at 7:07 PM, Jordan Brown <[email-masked]> wrote:
> It would probably be names with no atsigns that look like "S-xxx-yyy-zzz..."
> - basically, the obvious extension of the existing "bare UID/GID"
> convention.

You could argue that an unresolvable SID's name is the stringified
SID.  Now all you need is a domain part.  No domain part would be fine
with me, but technically that's not allowed by the RFC.

Possible choices for domain part: the hostname of the client, the
hostname of the server, or an agreed constant (e.g., "oracle.com").

>> WG.  For full effect wait until after you ship before telling the WG,

Well, (1) is kinda like that, particularly if you don't include a
domain part.  If you do include a domain part then you're still within
the letter of the spec.

Also, for even better effect wait until someone else reports Solaris'
new behavior ;)

> Silently dropping ACEs seems like a Really Bad Idea.

Of course.  I just thought I'd list that as an option.

> Also, remember the mantra:  It's Not Just ACEs.

I don't get the reference.

Nico
--

---

From: Rick Macklem <[email-masked]>
Date: Mon, 20 Jun 2011 21:39:03 -0400 (EDT)

> "S-xxx-yyy-zzz..." - basically, the obvious extension of the existing
I have a couple of questions related to this:
1 - Does the server need to know about "special semantics" for these?
    (It wasn't clear to me whether or not that's the case. If not, I
     don't see why Olga's suggestion of just <string>@<your.domain>
     isn't sufficient.?)
2 - What to the Kerberos principals for these things look like?
    (If they don't have a Kerberos principal, how is a server supposed
     to know when the "who" for an ACE matches the requestor at the
     server when it enforces access via an ACL?)

If this was clarified earlier in the thread, then just ignore my noise, rick

---

From: Nico Williams <[email-masked]>
Date: Mon, 20 Jun 2011 20:50:54 -0500

>     don't see why Olga's suggestion of just <string>@<your.domain>

For unresolvable non-special SIDs, no.

For most special SIDs the server only needs to know their semantics in
DENY ACEs.

For a few special SIDs the server needs to know their semantics in
ALLOW ACEs as well.

All multi-protocol file servers that support CIFS *and* NFSv4 need to
deal with this problem.  Quite a few NFSv4 implementors also implement
CIFS (either directly or indirectly, in the case of Linux, for
example).  IMO this means that the WG ought to tackle this problem.

> 2 - What to the Kerberos principals for these things look like?

There's no Kerberos principals for group ACE whos.  Similarly here.

>     server when it enforces access via an ACL?)

Same as with groups.  In the case of unresolvable, non-special SIDs,
the server should simply assume that the client principal is NOT a
member of the group.

Nico
--

---

From: Olga Kornievskaia <[email-masked]>
Date: Tue, 21 Jun 2011 12:13:53 -0400

> as opposed to the LSA API).

Can you provide an example of something that is not resolvable? Are we
talking about a linux box trying to resolve something or windows box?
As far as I know, any windows machine has the necessary api to resolve
all well-known SIDs. If it's linux, than I believe LDAP is flexible
enough to provide a mapping from a string that represents a SID to
some name.

> b) Some well-known SIDs have special semantics that the server has to

Sure I agree BUT the reality is that servers don't implement it (I'll
guess because it is not a MUST in the NFS4 protocol). Thus I think
it's not a good strategy for client-side implementors to assume
anything about it (ie CITI is currently implementing an NFS41
*windows* client so I actually know what Jordan is talking about
because we have implementing this mapping of special sids).

Besides, I think identity mapping is really outside of the scope of
the protocol. The RFC specifies sufficient common, on-the-wire format
of nfs4name@nfs4domain. Then each side needs to implement/provide a
configurable identity mapping mechanism. The rest is just an
administrative policy of an NFS4 domain. Mapping mechanism and policy
should NOT be dictated by the RFC.

---

From: Jordan Brown <[email-masked]>
Date: Tue, 21 Jun 2011 09:27:00 -0700

> with me, but technically that's not allowed by the RFC.

Whether it's legal is debatable.  RFC 3530 Section 5.8 (Interpreting owner 
and owner_group), sixth paragraph, explicitly contemplates using no-@ 
strings for untranslatable identities.

> hostname of the server, or an agreed constant (e.g., "oracle.com").

The "agreed constant" solution would be the "generic solution for 
representing internal forms" that I was discussing.  In this case, ideally 
the agreed constant would be something like "sid.microsoft.com" or 
"sid.nfsv4.org".

> I don't get the reference.

The problem applies to the owner and owner_group attributes too, not just ACEs.

---

From: Jordan Brown <[email-masked]>
Date: Tue, 21 Jun 2011 09:33:32 -0700

On 06/20/11 18:50, Nico Williams wrote:
> On Mon, Jun 20, 2011 at 8:39 PM, Rick Macklem<[email-masked]>  wrote:
>> Jordan Brown wrote:
>>      don't see why Olga's suggestion of just<string>@<your.domain>
>>      isn't sufficient.?)
>

Nico and I seem to disagree here - if a server doesn't understand a SID 
it's presented with (and here let's assume that it was presented using a 
non-NFSv4 mechanism like SMB so we don't have to discuss how it got there), 
I'd say that the server should blindly accept and store the SID and return 
it on demand.  Nico seems to think that that would be unacceptable for some 
SIDs.

> the server should simply assume that the client principal is NOT a

Correct.  It's not possible to authenticate as an identity that the server 
doesn't understand.

Think of the behavior with bare numeric POSIX UID/GID.  (Section 5.8 
seventh paragraph.)  Such an identifier might well refer to an entity that 
has no Kerberos principal.

---

From: Jordan Brown <[email-masked]>
Date: Tue, 21 Jun 2011 09:52:17 -0700

On 06/21/11 09:13, Olga Kornievskaia wrote:
> On Mon, Jun 20, 2011 at 6:19 PM, Nico Williams<[email-masked]>  wrote:
>> On Mon, Jun 20, 2011 at 5:04 PM, Olga Kornievskaia<[email-masked]>  wrote:
> all well-known SIDs.

Yes, Windows systems can resolve all well-known SIDs... or at least all 
well-known SIDs that were known when they were released.

However (it appears from a black-box perspective) they resolve well-known 
SIDs using an internal table.

There are existing well-known SIDs that can't be looked up in AD using 
LDAP.  S-1-5-1 "Dialup" is one of them.  I don't offhand know whether that 
one is resolvable using LSA RPC; I'd have to do a special build to check.

Presumably no AD system can resolve a well-known SID introduced after its 
well-known SID table was created.

In addition, applications have been observed creating SIDs using their own 
rules, with no mechanism to resolve them.

In addition, a SID could refer to a user or group that no longer exists and 
so is not resolvable.

> If it's linux, than I believe LDAP is flexible

It's Solaris, but the issues are similar.  LDAP is certainly flexible 
enough to store the mapping, but I can't rely on the user to populate their 
AD with all of the known and unknown SIDs that might be encountered.

> guess because it is not a MUST in the NFS4 protocol).

Also because their file systems and authorizations subsystems don't support 
the concepts.  Protocols setting "requirements" only go so far in driving 
the behavior of the rest of the system.

> Thus I think

The problem there is not so much client-side *implementers* assuming 
anything - it's client-side *users* and *applications* assuming things.

However, this really doesn't seem like an NFSv4 problem.  You're very 
unlikely to see these identities outside an environment that includes SMB, 
and the server vendors will chose to implement or not-implement these 
special semantics based on their SMB demands, not based on NFSv4 demands.

---

From: Nico Williams <[email-masked]>
Date: Tue, 21 Jun 2011 11:54:18 -0500

> enough to provide a mapping from a string that represents a SID to

Windows can resolve these kinds of SIDs:

 - Well-known SIDs

 - Domain SIDs (S-1-5-<domain-RIDs>-<user/group-RID>) for domains in
the joined forest and trusted forests/domains;

 - Local SIDs (S-1-5-<computer-RIDs>-<user/group-RID>);

 - SIDs local to a remote server (S-1-5-<computer-RIDs>-<user/group-RID>).

Windows *cannot* resolve these kinds of SIDs:

 - SIDs local to remote systems to which the local host has no connection;

   This is the one that usually causes problems.  This happens when,
for example, you put a SQL Server DB on a CIFS share.  SQL Server ends
up creating ACLs that contain ACEs with client-local SIDs as who
values.  The server gladly accepts such ACLs.  Later, when another
client, or server-local application for that matter, looks at that ACL
they'll not be able to resolve those SIDs.

 - Session SIDs (since they identify sessions, not users nor groups);
(these don't belong in ACLs anyways)

 - SIDs that don't conform to any conventions that Windows knows how to resolve.

There's some SID types I didn't mention, like SIDs representing
privileges or MAC labels.

> because we have implementing this mapping of special sids).

The reality is that any multi-protocol server that implements CIFS has
to implement these.

How many NFSv4 server implementations *only* share files via NFSv4?
When you consider the whole *system*, I think the answer is probably
"none", or maybe "one".  (Linux users, I'm sure, never think "oh, I
can't share this filesystem with Samba *and* NFSv4".  Surely you don't
mean to say that they do.)

> should NOT be dictated by the RFC.

I disagree vehemently.  ID mapping is a critical component of the
system, and it has interoperability externalities: name resolution
protocols and schemata.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 21 Jun 2011 11:58:39 -0500

> special semantics based on their SMB demands, not based on NFSv4 demands.

I can't believe you wrote that...

These are filesystem access protocols.  Implementors tend to want to
support several, or all of these: AFS, SMB/CIFS, NFSv3, NFSv4, SFTP,
WebDAV, and probably a few others too.  The lowest common denominator
is pretty unusable in enterprise systems.

Therefore it is important to aim for more than the lowest common
denominator.  Since NFSv4 *is* the most advanced Standards-Track
Internet remote file access protocol, it seems incumbent on the WG to
aim for better than the lowest common denominator, else NFSv4 will
fail.

Nico
--

---

From: Jordan Brown <[email-masked]>
Date: Tue, 21 Jun 2011 11:56:05 -0700

On 06/21/11 09:58, Nico Williams wrote:
> On Tue, Jun 21, 2011 at 11:52 AM, Jordan Brown<[email-masked]>  wrote:

It seems to me that there are three kinds of server implementers in the world:

- Those that support only SMB.  Since they don't support NFS, they aren't a 
factor here.
- Those that support both SMB and NFS.  They will support Windows special 
semantics to the extent that's required to make their SMB clients happy, 
and that support will probably carry over, more or less, to their NFS clients.
- Those that support only NFS.  They will have essentially no interest in 
supporting Windows special semantics, and if the NFS standard purports to 
require them to do so they will likely just laugh; they will not (for 
instance) restructure their file system to support those "requirements".

Having requirements that vendors will laugh at is just bad.

---

From: Olga Kornievskaia <[email-masked]>
Date: Tue, 21 Jun 2011 14:57:34 -0400

On Tue, Jun 21, 2011 at 12:33 PM, Jordan Brown <[email-masked]> wrote:
> Nico and I seem to disagree here - if a server doesn't understand a SID it's
> presented with (and here let's assume that it was presented using a

The wording in the spec in 6.2.1. is "servers should accept every ACL
that they can without compromising security". Thus it is left to the
server's discretion as to how to handle this. I believe linux
implementation is such that if the server can't map user's identity
than the setattr for an acl or owner/group attributes will fail. If
the server doesn't understand the identity ("who") of the ACE being
set how can it enforce the ACL later? One could argue that at the time
of enforcement the mapping is valid but I'm not sure about the
security implications -- denial of access to a future user (maybe
that's a none sure)...

I don't see anything wrong with appending some string for the nfs4
domain name for the well-known sids. I do disagree that it should be
addressed by the protocol. In the current scenario we are considering
how to handle these special identities that are called SIDs. What if a
few years from now somebody comes up with a new type of special
identities that are similar to SIDs -- ie string formated
representation NIRS (new identity representation structures) -- do we
again change the spec to say NIRS should be [email-masked]. If we
modify the spec to say all special ids should be appended with
sid.nfs4.org, then [email-masked] would be confusing. Then
something new come along and the cycle repeats. In the end it can all
be just an implementation detail: as long as your client appends the
same string and the server accepts it your problem is solved. All is
need is a flexible identity mapping mechanisms on the client and
server that maps "local" format to and from "nfs4" format.

As for you comment that you don't worry about "implementors" but worry
about "users". We'll that's administration question. Why did we assume
that DNS administrators will be able to properly configure name to ip
and back for each dns client and dns server? Even know, we assume that
NFS4 administrators properly configure and populate their id mapping
mechanism (passwd file or idmapd config or whatever else)...

---

From: Jordan Brown <[email-masked]>
Date: Tue, 21 Jun 2011 12:28:34 -0700

On 06/21/11 11:57, Olga Kornievskaia wrote:
> server's discretion as to how to handle this.

Sounds right to me.

> sid.nfs4.org, then [email-masked] would be confusing.

That kind of transition is exactly why I suggested that mechanism.

I'm confused as to why you might think that it would ever be valid to say 
[email-masked]; @sid.nfs4.org would be reserved for SIDs, while to 
represent a NIRS you'd have to use @nirs.nfs4.org.  That's the whole idea: 
  by looking at the domain part, you can tell what kind of identifier to 
expect in the local part.

> Then

Yes, give or take details.  The parties need to map the "internal" form 
into the NFSv4-tagged version, so that the receiver knows which 
representation scheme is being used.

> mechanism (passwd file or idmapd config or whatever else)...

I'm not sure exactly which comment you're responding to here.

One comment that I made was that it wasn't client implementers' 
expectations that were important, it was users' expectations.  By and 
large, I wouldn't expect NFS client implementers to have expectations about 
the behavior of ACLs involving special identifiers.  The client 
implementers aren't the ones who will put those entries into the ACLs - 
those entries will come from the applications and users that they support, 
and it is those applications and users that truly care who gets access and 
who does not.

Another comment that I made was that I couldn't assume that administrators 
would populate their LDAP servers with all known and unknown SID-to-name 
mappings.  First, it's just not possible - applications can make up SIDs 
using their own rules and it may not be possible to enumerate all of them. 
  Second, even if it was, comparing that list to DNS host entries isn't 
appropriate.  DNS host entries apply directly to the local environment, 
describing the actual hardware found on the user's network.  On the other 
hand, special SIDs are defined by some software vendor or vendors and have 
nothing at all to do with the configuration of the local network; they are 
an implementation detail that should be invisible to administrators and 
users alike (except when explicitly used, of course).

---

From: Olga Kornievskaia <[email-masked]>
Date: Tue, 21 Jun 2011 16:15:22 -0400

> expect in the local part.

I was just saying that as soon as the new spec is written that has a
special domain defined for SIDs something new comes along. Sure we can
define a special domain format (like <type>.<protocol>) . But
"nirs.nfs4.org" is too much like a dns name, so do we worry about
these special domain conflicting with real DNS domains?

Overall, I'm arguing none of this should be defined by the spec. It
all sounds too much like administrative policies for a given
implementation. I think nfs4user@nfs4domain is general enough.

> Yes, give or take details.  The parties need to map the "internal" form into
> the NFSv4-tagged version, so that the receiver knows which representation
> scheme is being used.
>
> One comment that I made was that it wasn't client implementers' expectations
> that were important, it was users' expectations.  By and large, I wouldn't
> expect NFS client implementers to have expectations about the behavior of
> ACLs involving special identifiers.  The client implementers aren't the ones
> who will put those entries into the ACLs - those entries will come from the
> applications and users that they support, and it is those applications and
> users that truly care who gets access and who does not.
>

If there is no identity mapping, then that identity doesn't exist and
thus can't have privileges assigned to it. You must assume that all
the needed mapping are there. (Again i'm not sure what it means to
accept an ACL for an identity that the server can't map).

> users alike (except when explicitly used, of course).

I don't follow your argument here. "that list" to what "DNS host
entries"? Example I'm thinking is,  a user is creating a file and
needs to create and ACL with some privileges. The user wants to give
"read" access to an identity represented by a sid of "S-X-Y-Z".  Let's
say it's a special sid for "dialup" service. It is sufficient on the
client side, to map S-X-Y-Z to "dialup@yourdnsdomain" and have a
reverse mapping on the server.

These on-the-fly SIDs can't be used for ACLs unless there exists a
mapping to windows/unix account/identity. Let's just take the case of
where we try to access this file protected by this on-the-fly SIDs as
that on-the-fly SID identity. What kind of identity will be in the RPC
header (auth_sys's uid or rpcsec_gss kerberos identity)? How would
have this on-the-fly SID be mapped to that identity?

---

From: Olga Kornievskaia <[email-masked]>
Date: Tue, 21 Jun 2011 16:20:57 -0400

Let me just add, I'm all for some sort of implementation convention
that we can all establish during our interoperability testing events
(connectathons and bakeathons). But I just don't see the need for a
spec (issues of identity management is a hard problem).

---

From: Nico Williams <[email-masked]>
Date: Tue, 21 Jun 2011 15:40:49 -0500

> - Those that support only SMB.  Since they don't support NFS, they aren't a

Sure they are: because NFSv4 can be added later.  And vice-versa.

---

From: Nico Williams <[email-masked]>
Date: Tue, 21 Jun 2011 15:41:45 -0500

> spec (issues of identity management is a hard problem).

So if your implementation and Jordan's don't interop that's OK?  Fine, I guess.

---

From: Olga Kornievskaia <[email-masked]>
Date: Tue, 21 Jun 2011 16:52:34 -0400

> So if your implementation and Jordan's don't interop that's OK?  Fine, I guess.

Why would we not interoperate if we test against each other?

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 21 Jun 2011 20:53:21 +0000

Note that relying on testing events such as Connectathon/Bakeathon
is insufficient.  Implementations will come into existence that
are constructed by those that don't attend those events and are
not subscribed to this alias nor look at its archives.

IETF RFCs (standards track or informational) and IANA registries are
the only method of describing semantics that lead to interoperable
implementations.  Anything else will result in failure.

Spencer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Olga Kornievskaia
> Sent: Tuesday, June 21, 2011 1:21 PM
> To: Jordan Brown
> Cc: Nico Williams; Rick Macklem; [email-masked]
> Subject: Re: [nfsv4] Representing Windows special identities across NFSv4
> 
> Let me just add, I'm all for some sort of implementation convention that
> we can all establish during our interoperability testing events
> (connectathons and bakeathons). But I just don't see the need for a spec
> (issues of identity management is a hard problem).
> 
> >>> The wording in the spec in 6.2.1. is "servers should accept every
> >>> ACL that they can without compromising security". Thus it is left to
> >>> the server's discretion as to how to handle this.
> >>
> >> Sounds right to me.
> >>
> >>> addressed by the protocol. In the current scenario we are
> >>> considering how to handle these special identities that are called
> >>> SIDs. What if a few years from now somebody comes up with a new type
> >>> of special identities that are similar to SIDs -- ie string formated
> >>> representation NIRS (new identity representation structures) -- do
> >>> we again change the spec to say NIRS should be [email-masked].
> >>> If we modify the spec to say all special ids should be appended with
> >> I'm confused as to why you might think that it would ever be valid to
> >> say [email-masked]; @sid.nfs4.org would be reserved for SIDs,
> >> while to represent a NIRS you'd have to use @nirs.nfs4.org.  That's the
> whole idea:
> >>  by looking at the domain part, you can tell what kind of identifier
> >> to expect in the local part.
> >>
> >
> >>> something new come along and the cycle repeats. In the end it can
> >>> all be just an implementation detail: as long as your client appends
> >>> the same string and the server accepts it your problem is solved.
> >>> All is need is a flexible identity mapping mechanisms on the client
> >>> and server that maps "local" format to and from "nfs4" format.
> >>
> >> Yes, give or take details.  The parties need to map the "internal"
> >> form into the NFSv4-tagged version, so that the receiver knows which
> >>> As for you comment that you don't worry about "implementors" but
> >>> worry about "users". We'll that's administration question. Why did
> >>> we assume that DNS administrators will be able to properly configure
> >>> name to ip and back for each dns client and dns server? Even know,
> >>> we assume that
> >> large, I wouldn't expect NFS client implementers to have expectations
> >> about the behavior of ACLs involving special identifiers.  The client
> >> implementers aren't the ones who will put those entries into the ACLs
> >> - those entries will come from the applications and users that they
> >> support, and it is those applications and users that truly care who
> gets access and who does not.
> >>
> >> Another comment that I made was that I couldn't assume that
> >> administrators would populate their LDAP servers with all known and
> >> unknown SID-to-name mappings.  First, it's just not possible -
> >> applications can make up SIDs using their own rules and it may not be
> possible to enumerate all of them.
> >
> >>  Second, even if it was, comparing that list to DNS host entries
> >> isn't appropriate.  DNS host entries apply directly to the local
> >> environment, describing the actual hardware found on the user's
> >> network.  On the other hand, special SIDs are defined by some
> >> software vendor or vendors and have nothing at all to do with the
> >> configuration of the local network; they are an implementation detail
> >> that should be invisible to administrators and users alike (except when
> explicitly used, of course).
> >

---

From: Nico Williams <[email-masked]>
Date: Tue, 21 Jun 2011 16:01:18 -0500

> implementations.  Anything else will result in failure.

I was hoping I'd not be alone in holding to that view here!  Thanks
for saying this so well.

Nico
--

---

From: Olga Kornievskaia <[email-masked]>
Date: Tue, 21 Jun 2011 17:07:30 -0400

> I was hoping I'd not be alone in holding to that view here!  Thanks

But apparently the NFS4 standard went along without specifying any
identity mapping methods in the first place.

I'm trying to understand what's the question at hand here: Are we
trying to say the current spec fails to define the identity mapping
methods and it should be address? Or is the question of a simple: can
we add a new general format to the special identities but again
leaving all of it as a may or should? If so then we again won't have
server implementing it and then clients would need to create ways to
deal with it (which is what we are doing now).

Unless the spec changes all of this into a MUST, I think it's a waste of time.

---

From: Nico Williams <[email-masked]>
Date: Tue, 21 Jun 2011 16:11:16 -0500

> identity mapping methods in the first place.

So?  So it was incomplete.  Now people realize that there are interop
issues related to ID mapping:

 - issues related to name resolution protocols, LDAP schemas, and
service discovery;
 - issues related to well-known SIDs and other equivalents (but mostly
just SIDs);
 - issues related to unresolvable internal identifiers (such as SIDs).

We should not punt now just because we did not know about these issues
earlier, or because we punted earlier.

> Unless the spec changes all of this into a MUST, I think it's a waste of time.

Yes, there will have to be new requirements.

---

From: Nico Williams <[email-masked]>
Date: Tue, 21 Jun 2011 16:21:20 -0500

> Yes, there will have to be new requirements.

The immediate issues are:

 - how to represent unresolvable internal IDs (presenting
unknown@domain is lame, and means you can't accept that in SETATTR);

   (for this it may be best to just use stringified SID@constant-domain)

 - how to represent well-known SIDs.

   (for this I think we may need new special ACE who values)

Introducing new special ACE who values with critical semantics is
problematic.  MSFT last did that when they released win2k.  We need to
say something about how clients and servers handle special ACE who
values that they don't understand.  We might be able to avoid dealing
with special SIDs like "Creator Owner" by specifying some useful ACL
mapping behavior that allows the ACEs that refer to Creator Owner to
be preserved even when edited via NFSv4 -- in which case there may not
even be a need to specify anything, but that's not clear yet.

Nico
--

---

From: <[email-masked]>
Date: Tue, 21 Jun 2011 17:26:38 -0400

I am not so sure that it is quite so black and white.  Neither approach is sufficient on its own.  It is distinctly possible for two people to read the same technical specification, no matter how seemingly simple, and come away with two different interpretations.  That's where interoperability testing is required.  That testing can either occur at an event such as Connectathon/Bakeathon or at a customer site.  (It simply isn’t economically feasible or even possible to do sufficient testing in-house.)

I would hold up NFSv3 as the example here.  We have lots of interoperable implementations in the marketplace, but not due to the specification alone and not due to testing alone either.  A specification, as strong as we can figure out how to reasonably make it, is required, followed by as much interoperability testing as we can reasonably do as well.

		ps

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nico Williams
Sent: Tuesday, June 21, 2011 5:01 PM
To: Spencer Shepler
Cc: Jordan Brown; Rick Macklem; [email-masked]
Subject: Re: [nfsv4] Representing Windows special identities across NFSv4

Nico

---

From: Olga Kornievskaia <[email-masked]>
Date: Tue, 21 Jun 2011 17:35:19 -0400

> earlier, or because we punted earlier.

Actually I take it back there a very simple mapping strategy specified
by the spec: client maps it's local identity into a form "user@domain"
and server maps it back. Since special identifies are not a MUST, then
even special identities like OWNER@ can we mapped into some "fake"
identity "owner@domain". Administratively, one has to not issue user
names with those identities.

I raise the question again: if an identity (SID) is unresolvable then
an RPC using that SID can't take place. I don't see SIDs as "issues",
they are just local identities that can easily be mapped to
user-friendly names (if required). And if both sides understand SIDs
than on-the-wire names could just be SIDs. It's all just
configuration.

---

From: Nico Williams <[email-masked]>
Date: Tue, 21 Jun 2011 16:38:29 -0500

> I am not so sure that it is quite so black and white.  Neither approach is sufficient on its own.  It is distinctly possible for two people to read the same technical specification, no matter how s…

The IETF motto is "rough consensus and running code".  Rough consensus
is documented in RFCs.  We need those so that subsequent implementors
can figure out what to do.  Interop testing for published specs gets
much easier after products have shipped.  Interop testing events are
nice while we're developing the specs.  But we need specs.  Just
testing will not do.

Nico
--

---

From: Jordan Brown <[email-masked]>
Date: Tue, 21 Jun 2011 14:50:15 -0700

On 06/21/11 13:15, Olga Kornievskaia wrote:
> special domain defined for SIDs something new comes along.

Sure.  Any scheme has to be extensible to allow for that new thing.

> Sure we can
> define a special domain format (like<type>.<protocol>) . But

Not at all; that's the beauty.  Since the NFSv4 WG owns nfs4.org, it can 
reserve nirs.nfs4.org for this purpose.  Similarly, Microsoft could reserve 
sid.microsoft.com (or whatever).

> implementation. I think nfs4user@nfs4domain is general enough.

Sorry, you're using the words "administrative policy" and "implementation" 
in the same sentence, and in my lexicon those two don't go together.

Are you saying that this is something that should be handled by some 
administrator at an end user site, that they should configure all of their 
systems in some consistent way to handle this case?  First, how could they? 
  How could they configure a system to handle SIDs if the underlying OS 
implementation can't handle them?  Second, is it really appropriate to 
expect those administrators to handle this kind of detail?

Are you saying that this is something that should be handled by the vendors 
of the NFS client and server software?  I certainly think it should be, but 
without standardization how can one ever expect two implementations to 
interoperate?

> accept an ACL for an identity that the server can't map).

The schemes being discussed here - mechanisms for passing bare SIDs across 
the protocol, analogous to the existing mechanisms for passing bare 
UID/GIDs across the protocol - allow clients and servers to "map" all SIDs, 
in the sense that they can trivially translate SIDs to and from the 
on-the-wire representation.  They may or may not assign any special 
semantics to those SIDs, but they would be able to transparently move them 
across the protocol and (local file system capabilities permitting) store 
them in the file system and retrieve them intact from the file system.

> reverse mapping on the server.

So a minimum-wage clerk is running some Windows application, and it uses 
(well under the covers) S-1-5-1, and fails because the server rejects the 
request because there's no mapping.  The clerk (or the barely-better-paid 
IT tech) has to somehow figure out that that's what's failing, talk to the 
LDAP administrator, convince them to add this entry, and repeat next week 
when a different clerk happens to cause the application to use S-1-5-2. 
Can that possibly be the right answer?

Consider also that some applications will export system-local SIDs (that 
is, SIDs that start with the particular client system's machine SID) to 
file metadata on a server.

Consider also that applications can make up SIDs for their own nefarious 
purposes, following their own rules.  See, for instance:
http://blogs.msdn.com/b/larryosterman/archive/2004/09/03/225332.aspx

> mapping to windows/unix account/identity.

Windows systems can natively handle SIDs, and so need no mapping.  So can 
Solaris systems (starting with Solaris 11).

Systems that can't handle SIDs natively won't be able to handle SIDs 
specified in this new form... they're pretty much unaffected by the change, 
required to cope somehow with information they don't understand.

> Let's just take the case of

I don't have a clue whether it'd be possible to get the NFSv4 credential to 
include such a SID.  In fact, in certain cases it sure better not be 
possible - S-1-3-0 (Creator Owner) is not intended to match a user's 
identity; instead, it's an instruction to the file system as to how to 
create ACLs for new files created in the directory.

The problems that we are seeing and expect do not involve access control 
failures per se.  Rather, they involve tools like "cp" and "ls" failing 
because they are unable to retrieve metadata about the file or, in the case 
of cp, they are unable to copy the metadata to a newly created file.

---

From: Jordan Brown <[email-masked]>
Date: Tue, 21 Jun 2011 15:41:18 -0700

> identity mapping methods in the first place.

The question isn't identity mapping, per se.

The question is identity namespace.  NFSv4 defines four identity name syntaxes:

name@domain
     Relatively obvious:  a name that has meaning relative to the domain.
name@
     Special names defined by NFSv4.
<digit-string>
     Legacy POSIX UID/GID, meaningful only to POSIX systems and even
     there meaningful only with appropriate cross-system coordination.
<everything else with no @>
     No defined meaning; peer's ability to interpret is dubious.

What we're saying is that that's not enough, that there are classes of 
identities that can't be readily mapped into any of those.  (Well, they can 
be mapped into the last, but that's useful only if that last is then 
divided to form another defined class.)

---

From: Rick Macklem <[email-masked]>
Date: Tue, 21 Jun 2011 19:49:32 -0400 (EDT)

> No defined meaning; peer's ability to interpret is dubious.
Actually you could also have
  @name
  which is not defined at this point, but might be useful for this?

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 22 Jun 2011 01:20:59 +0000

I am happy to see that we are all in agreement on this topic.

Documentation and testing are required.  Neither in-of-itself
is sufficient.  Note that my message said "lead to interoperable implementations".

So, now that we have that settled, let's move on to deciding if there
is anything needed for interoperability and if so, how we would
like to document it and test it.

Spencer

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 21, 2011 2:27 PM
> To: [email-masked]; Spencer Shepler
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [nfsv4] Representing Windows special identities across NFSv4
> 
> I am not so sure that it is quite so black and white.  Neither approach is
> sufficient on its own.  It is distinctly possible for two people to read
> the same technical specification, no matter how seemingly simple, and come
> away with two different interpretations.  That's where interoperability
> testing is required.  That testing can either occur at an event such as
> Connectathon/Bakeathon or at a customer site.  (It simply isn’t
> economically feasible or even possible to do sufficient testing in-house.)
> 
> I would hold up NFSv3 as the example here.  We have lots of interoperable
> implementations in the marketplace, but not due to the specification alone
> and not due to testing alone either.  A specification, as strong as we can
> figure out how to reasonably make it, is required, followed by as much
> interoperability testing as we can reasonably do as well.
> 
> 		ps
> 
> 
> Nico Williams
> > Note that relying on testing events such as Connectathon/Bakeathon is
> > insufficient.  Implementations will come into existence that are
> > constructed by those that don't attend those events and are not
> > subscribed to this alias nor look at its archives.
> >
> I was hoping I'd not be alone in holding to that view here!  Thanks for
> saying this so well.
> 
> Nico
> --