Subject: Re: [nfsv4] New I-D: draft-falkner-nfsv4-acls-00

From: Lisa Week <[email-masked]>
Date: Wed, 02 Nov 2005 15:11:23 -0700

Hi Gordon,

Thank you for sending this summary out.  I have put some responses inline.

- Lisa

Gordon Waidhofer wrote:
> Notes from the NAS Conference in Santa Clara 10/18-10/20.
> This doesn't capture all comments.
> 
> The IDENTIFIER_GROUP flag may be problematic for some
> platforms, like NT. What does [email-masked] with IDENTIFER_GROUP==0
> mean? NT doesn't allow both a user 'staff' and a group 'staff'.
> The NT SIDs (Security Identifiers) are always unique. A lookup
> of the SID will tell if its group/user/alias/etc.

An ACE with a who of "[email-masked]" and with IDENTIFIER_GROUP == 0 
means the ACE applies to *user*, "[email-masked]".

This should be taken into account when doing access checks as well as 
when determining whether or not to allow the setting of an ACL.

For instance, if a client is trying to do a SETATTR of ACL against a 
server (regardless of the platform) and the ACL contains an ACE with 
who="[email-masked]" and the ACE4_IDENTIFIER_GROUP flag is not set, then 
the server should check to see if there is a *user* named 
"[email-masked]".  If  a *user* named "[email-masked]" exists, set the 
ACL.  If a *user* named "[email-masked]", doesn't exist, return 
NFS4ERR_BADOWNER to the client.

Thoughts?

> 
> NFSv4 ACLs are largely believed to be first match. This is
> somewhat like POSIX ACLs being a directed match. NT ACLs,
> I believe, can accumulate permissions. This might be only
> when MAX_ALLOWED is used. The MAX_ALLOWED algorithm (if
> I recall correctly) is:
> 
> 	rights (principle, acl) {
> 		int	denied = 0, granted = 0;
> 
> 		foreach ace in acl
> 			if match (ace->who, principle)
> 				if ace is ALLOW
> 					granted |= ace->rights &~ denied
> 				elseif ace is DENY
> 					denied |= ace->rights
> 				endif
> 			endif
> 		endfor
> 		return granted
> 	}
> 

Sorry for any confusion, but NFSv4 ACLs actually do also accumulate 
permissions and it is pretty much what you described above.

As stated in RFC3530:
   "To determine if a request succeeds, each nfsace4 entry is processed
    in order by the server.  Only ACEs which have a "who" that matches
    the requester are considered.  Each ACE is processed until all of the
    bits of the requester's access have been ALLOWED.  Once a bit (see
    below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it is no longer
    considered in the processing of later ACEs.  If an ACCESS_DENIED_ACE
    is encountered where the requester's access still has unALLOWED bits
    in common with the "access_mask" of the ACE, the request is denied.
    However, unlike the ALLOWED and DENIED ACE types, the ALARM and AUDIT
    ACE types do not affect a requester's access, and instead are for
    triggering events as a result of a requester's access attempt. "

> What happens if the name service is down? Effectively the UI
> and API for ACLs would be disabled. If someone is trying to
> change an ACL, this is usually a read-modify-write operation.
> Substituting "nobody" for failed lookups ([email-masked]) gives
> a bad read of ACLs through the API. If its modified and written
> back, the ACL is trashed. Sam's take is the read should fail
> to prevent this scenario.

Currently the Solaris client fails the request to read the ACL if an ACE 
has a "who" which can't be mapped to a valid user/group on the client. 
This is to protect clients doing a read-modify-write operation of the 
ACL (i.e. setfacl -m on Solaris) from inadvertently setting an ACL which 
has been modified (by changing the unmappable user/group to "nobody") 
because of the inability for the client to map users/groups.

We will be looking into other possibilities for Solaris.  One possible 
solution recommended by Trond (as also described below) is to just not 
map the user/group on the client, but to use the raw ACE who strings.

> 
> How does DELETE/DELETE_CHILD interact? Sam and Lisa's draft has
> pseudo-code. IBM's native ACLs require that DELETE be granted on
> the object *AND* DELETE_CHILD be granted on the enclosing directory.
> NetApp allows/denies the delete if DELETE on the object specifically
> ALLOW/DENY. Otherwise, with the object effectively silent, DELETE_CHILD
> on the parent directory is consulted. This is believed to be consistent
> with NT behaviour.
> 
> There was a request in the audience for providing good tools
> for managing ACLs on migrated datasets. How does an admin take
> a large dataset (millions of files), move to an NFSv4 ACL capable
> file system, and set the ACLs? I suppose something more than -R
> is needed. It's a good question.
> 
> Sun (Sam and Lisa) are considering the API to native NFSv4 ACLs on
> Solaris. Their approach is to add opcodes to acl(2) to get/set/count
> the NFSv4 ACL. The existing opcodes for POSIX ACLs would continue to
> work and the translation between POSIX and NFSv4 ACLs would be done
> below the API.
> 

acl(2) and facl(2) have been modified in Solaris 10 to handle NFSv4 ACLs 
as well as POSIX-draft ACLs.

If you're interested, check out the code at opensolaris.org:
http://cvs.opensolaris.org/source/xref/usr/src/uts/common/syscall/acl.c#112

> Trond is experimenting with native NFSv4 ACLs on Linux. He'll use
> the Linux getxattr(), and also translate between POSIX/NFSv4 ACLs.
> Trond intends to save the "who" part of the ACL as a string just
> like the protocol. This is quite interesting because it avoids the
> name server problems. The "who" string will be saved 32-bit word
> aligned. The comparisson can be done word at a time rather than
> strcmp()ed. This is not unlike handling NT SIDs.
> 
> A brief conversation with Sergei of Hummingbird indicated that
> there is not much difficulty translating between NT and NFSv4 ACLs.
> 
> I would like to see getxattr() on all platforms with consistent
> attribute name and operand (value) data structures. It should
> be possible to coordinate. Tar 'x' encoding rules should also
> be defined.

Solaris doesn't actually have a getxattr() system call.

> 
> Others who were at the NAS Conference, please post anything
> I missed. Thanx.
> 
> Regards,
> 	-gww
> 
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>>Sam Falkner
>>Sent: Monday, October 17, 2005 5:46 PM
>>To: [email-masked]
>>Subject: [nfsv4] New I-D: draft-falkner-nfsv4-acls-00
>>
>>
>>A new internet draft for ACLs is now available.  It makes some  
>>clarifications
>>regarding ACL semantics, and discusses supporting NFSv4 ACLs in a POSIX
>>environment, including adhering to POSIX standards while improving
>>interactions between the mode and ACL attributes.
>>
>>We would like the working group chairs to consider this to be a work  
>>item
>>for this working group.
>>
>>We would appreciate any feedback, comments, etc.  In all likelihood,  
>>there
>>will be a Solaris implementation of NFSv4 ACLs in the near future,  
>>and we
>>would like to reach a consensus on these issues.
>>
>>In addition to discussion on this alias, we will both be attending  
>>the IETF
>>meeting in Vancouver, and hope to discuss this topic there.
>>
>>Thanks!
>>
>>- Sam
>>
>>From: [email-masked]
>>Date: October 17, 2005 12:50:02 PM PDT
>>To: [email-masked]
>>Subject: I-D ACTION:draft-falkner-nfsv4-acls-00.txt
>>Reply-To: [email-masked]
>>
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts  
>>directories.
>>
>>
>>     Title        : NFS Version 4 ACLs
>>     Author(s)    : S. Falkner, L. Week
>>     Filename    : draft-falkner-nfsv4-acls-00.txt
>>     Pages        : 35
>>     Date        : 2005-10-17
>>
>>    NFS version 4 (specified in RFC 3530) Access Control Lists (ACLs)
>>    provide more fine grained control than previous file permission
>>    models, but before the full benefit of the model can be exploited,
>>    some changes and clarifications must be made.  This document will
>>    describe the details that implementors should consider in order to
>>    allow implementations to function and interoperate better.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-falkner-nfsv4-acls-00.txt
>>
>>To remove yourself from the I-D Announcement list, send a message to
>>[email-masked] with the word unsubscribe in the body  
>>of the message.
>>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>>to change your subscription settings.
>>
>>
>>Internet-Drafts are also available by anonymous FTP. Login with the  
>>username
>>"anonymous" and a password of your e-mail address. After logging in,
>>type "cd internet-drafts" and then
>>     "get draft-falkner-nfsv4-acls-00.txt".
>>
>>A list of Internet-Drafts directories can be found in
>>http://www.ietf.org/shadow.html
>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>Internet-Drafts can also be obtained by e-mail.
>>
>>Send a message to:
>>     [email-masked].
>>In the body type:
>>     "FILE /internet-drafts/draft-falkner-nfsv4-acls-00.txt".
>>
>>NOTE:    The mail server at ietf.org can return the document in
>>     MIME-encoded form by using the "mpack" utility.  To use this
>>     feature, insert the command "ENCODING mime" before the "FILE"
>>     command.  To decode the response(s), you will need "munpack" or
>>     a MIME-compliant mail reader.  Different MIME-compliant mail  
>>readers
>>     exhibit different behavior, especially when dealing with
>>     "multipart" MIME messages (i.e. documents which have been split
>>     up into multiple messages), so check your local documentation on
>>     how to manipulate these messages.
>>
>>
>>Below is the data which will enable a MIME compliant mail reader
>>implementation to automatically retrieve the ASCII version of the
>>Internet-Draft.
>>Content-Type: text/plain
>>Content-ID: <[email-masked]>
>>
>>_______________________________________________
>>I-D-Announce mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/i-d-announce
>>
>>_______________________________________________
>>nfsv4 mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/nfsv4
>>
>>
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 2 Nov 2005 16:49:38 -0600

> NFS4ERR_BADOWNER to the client.

Windows has a unified user/group namespace.  I think this means that
Windows NFSv4 servers can just ignore IDENTIFIER_GROUP when the ACE
subject domain is a Windows domain, both, on SETATTR and GETATTR.

> map the user/group on the client, but to use the raw ACE who strings.

But what would "raw ACE who strings" be?  They're not defined in
RFC3530...  Perhaps a format that is private to each server, thus simply
not interpretable by the client?  For that an implementor need only fail
to include an "@domain" in the subject string so as to avoid ambiguity
with non-raw ACE who strings, I think.

A standard encoding of raw ACE who strings might eventually be
desirable, though for now it would simply encourage non-interoperability
w.r.t. ACLs as clients would have to know how to deal with the internal
user/group identifier types for all server platforms that they'd like to
interop with...

Nico
--

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Wed, 2 Nov 2005 15:54:58 -0800

> subject domain is a Windows domain, both, on SETATTR and GETATTR.

I expect IDENTIFIER_GROUP will ultimately prove unworkable.

It is a bandaid for UNIX-type platforms so they know whether
to use getpwnam() or getgrnam(). Unified accounts (one namespace)
is likely the future.

Consider interoperability with a Windows system. There is a group "staff".
UNIX folks want the IDENTIFIER_GROUP!=0 so they can tell. But Windows
can't do that. There can not simultaneously be a user "staff" and a
group "staff". Interoperability between the UNIX and Windows systems
is precluded in sites that try to have both regardless of what edicts
exist in the NFSv4 protocol. There is absolutely no way to trick NT
into "staff" meaning two things.

So then the question is how important is the IDENTIFIER_GROUP
bit in UNIX environments? How much name collision between
users and groups exists? It is not as far fetched a constraint
as one might first think to say UNIX systems can not collide
user/group names because they have to face that anway due to NT.

Regards,
	-gww

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Wed, 2 Nov 2005 15:54:58 -0800

> user/group identifier types for all server platforms that they'd like to

Nico, I'm afraid I didn't quite follow this but I'd like to.

Perhaps the word "raw" is a stumbling block. Ignore it. Trond's
suggestion is that the "who" strings be saved by the native file
system. I think it's a good idea.

Regards,
	-gww

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Wed, 2 Nov 2005 16:31:49 -0800

> Solaris doesn't actually have a getxattr() system call.

Who should we talk to about that? :)

All APIs converging on getxattr(), even if not a system
call but a library interface, is the way to go. It will
make it easier for application programs to use the new
NFSv4 features on various platforms. For example, tar(1)
and tar(1)-like programs that had conforming APIs on
these platforms would readily run.

Disperate APIs would prove a barrier to application
programs using these features and, therefor, ultimately
be deterimental to NFSv4 flourishing. I don't think a
lack of conforming APIs would kill the deal, though
certainly slow things down. Rather, I believe having
conforming APIs between platforms would seal the deal
and promote rapid adoption by the apps.

I know APIs are beyond the scope of this reflector.
Still, it is a convenient place to nudge.

Regards,
	-gww

---

From: Lisa Week <[email-masked]>
Date: Wed, 02 Nov 2005 18:49:23 -0700

> subject domain is a Windows domain, both, on SETATTR and GETATTR.

So when you say that Windows has a unified user/group namespace that 
means that Windows requires the names of users/groups to be unique (i.e. 
- can't have a user named "staff" as well as a group named "staff"), right?

Regardless of that, the entity "staff" is still either a user or group 
in Windows, correct?  So, if that is the case, I don't know if I agree 
that Windows NFSv4 servers can just ignore IDENTIFIER_GROUP.  The thing 
I worry about is not only the fact that there is a unified user/group 
namespace in Windows, but the namespaces between the client and server 
may be inconsistent.  I'll try to explain the scenario that I'm thinking 
about, to let you know where I'm coming from.  If this isn't something 
to worry about, then perhaps Windows can ignore IDENTIFIER_GROUP...

A user on Client A is trying to set an ACL on Server B.
Client A has an group named "staff" defined.
Server B has a user named "staff" defined.
(Client A's "staff" != Server B's "staff")

Client A sends a SETATTR request to Server B with the following ACL in it:
     who = [email-masked]
     access mask = ACE4_WRITE_ACL
     type = ALLOW
     flags = IDENTIFIER_GROUP

If Server B ignores the IDENTIFIER_GROUP flag, it has just allowed an 
ACL to be set that gives user "staff" the ability to write the ACL.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 2 Nov 2005 20:01:22 -0600

> system. I think it's a good idea.

Please, no...

Name-based authorization is...  Bad.  What happens when users get
renamed?  That, BTW, happens very, very often.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 2 Nov 2005 20:06:56 -0600

> I expect IDENTIFIER_GROUP will ultimately prove unworkable.

I don't agree.  Of course it's workable.

Since Windows-based NFSv4 servers have to resolve SIDs to names and back
in order to support NFSv4 ACLs they also can determine if a given SID is
a group or user SID.

> can't do that.

Of course Windows *can* do that -- it involves a directory lookup, for
non-local groups, but, so what?  the server has to do the lookup already
anyways.

>                There can not simultaneously be a user "staff" and a
> group "staff".

True, but, the distinction between user and group nonetheless exists.

>                Interoperability between the UNIX and Windows systems
> exist in the NFSv4 protocol.

I don't get what you mean by "try both."

>                              There is absolutely no way to trick NT

RFC3530 does not require that that be possible.  It requires that it be
possible to know whether an ACE subject is a user or a group, something
Windows has no trouble doing.

> user/group names because they have to face that anway due to NT.

I think you've misunderstood the problem :/

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 02 Nov 2005 21:19:34 -0500

> renamed?  That, BTW, happens very, very often.

Tough. An NFSv4 namespace is defined in terms of names. 

 Not uids, 
 Not gids,
 Not some weird afs-or-windoze-like UUID/SID crap.

Renaming users can simply _not_ be supported unless you define some
universal backend that can update every ACE on every existing server
that refers to that particular name. I know of no such backend.

Cheers,
  Trond

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 2 Nov 2005 20:21:31 -0600

> - can't have a user named "staff" as well as a group named "staff"), right?

Right.

> in Windows, correct?

Correct.

>                       So, if that is the case, I don't know if I agree 
> that Windows NFSv4 servers can just ignore IDENTIFIER_GROUP.

Well, I think on GETATTR it would be nice for the client to be able to
tell "this ACE subject is a group, that one is a user," sure, but while
a server that never indicated this difference would not be conformant,
it would work, since any one name can only be a user or a group -- but
doing this puts the burden of knowing which it is on the client and/or
user, so it should be avoided.

Our difference is one of 'should not' versus 'can not' (or 'must not').

Looking at it from a standards compliance viewpoint, though, I agree
that Windows NFSv4 servers MUST NOT just ignore IDENTIFIER_GROUP.

>                                                               The thing 

No, it doesn't -- it has "staff" _in some domain_!  ;)

A subtle distinction, perhaps, but a crucial one nonetheless.

> Server B has a user named "staff" defined.

See above :)

> (Client A's "staff" != Server B's "staff")

Correcting this to:

(Client A's "[email-masked]" != Server B's "[email-masked]")

If the client and server don't agree as to the nature and contents of
foobarbaz.com, well that is categorically not NFSv4's problem.

In a Unix world we absolutely need to distinguish between users and
groups.  In a Windows world the distinction is much softer.

But a given domain either has a unified namespace or not, and the client
and server, if they can reference a given domain, simply *must* agree on
whether that domain's user/group namespace is unified -- nothing in
NFSv4 can save them if they don't, nothing.

All of this is moot though, since I agree that Windows NFSv4 servers, as
a matter of compliance, MUST NOT ignore the IDENTIFIER_GROUP flag.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 2 Nov 2005 20:24:34 -0600

> Tough. An NFSv4 namespace is defined in terms of names. 

Only *on the wire*.  Nothing, but nothing in RFC3530 requires that they
be so represented on disk, nothing.

You are free to choose that implementation approach, and I wish you
luck, while I'll just go buy stock in pharmaceuticals that make
pain killers :)  :)

> that refers to that particular name. I know of no such backend.

Nonsense.  And good luck :)

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 02 Nov 2005 21:35:18 -0500

> that refers to that particular name. I know of no such backend.

IOW: If you want the ability to rename users, then you should do that at
some local level which does not change the NFSv4 namespace. If that
means Windoze clients need to use SID@domain, as the NFSv4 user name
then fine - the protocol supports that.

Cheers,
  Trond

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 2 Nov 2005 20:40:11 -0600

> Nonsense.  And good luck :)

To clarify, I am asserting that the approach in this [expired][*] I-D

draft-williams-nfsv4-ace-mapping-01.txt

can be extended to deal with UID/GID<->SID mapping.

[*]  But you either have a copy already or know how to get copies of
     expired I-Ds :)

Cheers,

Nico
--

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Wed, 2 Nov 2005 18:45:02 -0800

> in order to support NFSv4 ACLs they also can determine if a given SID is

True. Why do that?

> non-local groups, but, so what?  the server has to do the lookup already

By "that" I mean have user "staff" and group "staff" simultaneously.
Of course it can look it up. I would agree that it's gonna
do the lookup anyway.

> True, but, the distinction between user and group nonetheless exists.

What is the distinction and why is it important?
(That's not a dumb question).

> I don't get what you mean by "try both."

Have both a user "staff" and a group "staff".

> I think you've misunderstood the problem :/

I can understand that reaction.

UNIX can also tell if a name is a user or a group.
If getpwnam() fails try getgrnam(). Right? And I think
we've already agreed that NT can tell.

So why have the IDENTIFIER_GROUP? Oh, so that the name
spaces are distinct rather than converged. Is
that a good idea?

Hmmm. Depends on what interoperability means.....

Suppose you have a customer that wants to mix NT and
UNIX nodes. Centeralized admin would be very nice,
so let's just say an LDAP/whatever server is being
used for all nodes.

But the constraints on administration are the
union of all platforms. NT can't have a user
and group both named "staff". An edict in the NFSv4
protocol called IDENTIFIER_GROUP ain't gonna change
that. Telling the customer that NFSv4 is good to go
but NT is busted ain't helpful.

So the problem isn't the protocol. The objective
is better interoperability, I should think.

Back to how necessary is IDENTIFIER_GROUP....
How necessary is it if UNIX systems are constrained
to keep user and group names distinct?

I anticipate that, through evolution, implementations
will botch IDENTIFIER_GROUP, which will lead to other
implementations ignoring it, which will lead to a
defined but dead bit. That's what I say
eventually unworkable.

Regards,
	-gww

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 2 Nov 2005 21:01:16 -0600

> > in order to support NFSv4 ACLs they also can determine if a given SID is

Why do what?

> Of course it can look it up. I would agree that it's gonna

I think you misunderstood me -- I didn't mean that Windows can make
separate user and group namespaces when it only has a unified one.  I
meant that Windows can tell whether a given name or SID names a user or
a group.

> (That's not a dumb question).

It's not a dumb question at all.

For Windows file servers the distinction isn't really useful.  For users
it is: groups stand for their member users, and their membership can
vary, but users are unitary.

> Have both a user "staff" and a group "staff".

You don't have.  Nothing in RFC3530 requires that that be possible.
RFC3530 requires that you be able to tell whether a given ACE subject is
a user or a group.

> I can understand that reaction.

:)

> UNIX can also tell if a name is a user or a group.

No, it can't -- you have to know a priori.

> we've already agreed that NT can tell.

NO!  That's NOT right.  I don't know of any program that does that,
ever.

Unix assumes separate user and group namespaces -- that they are
unified, in a Windows domain, does not break Unix.

The converse, trying to make separate and *overlapping* user and group
namespaces in a Windows domain would break Windows, if you could pull it
off.

> spaces are distinct rather than converged. Is

So you can have Unix NFSv4 implementations.

> Hmmm. Depends on what interoperability means.....

No, it doesn't.

> so let's just say an LDAP/whatever server is being

Let's just say that you're using Active Directory.

It has a unified user and group namepsace and you'll never have a user
named "staff" and a group named "staff" in the same Windows domain, but
if you have either a user or a group named "staff" in that domain,
you'll be able to tell which it is by looking it up in the directory.

> to keep user and group names distinct?

Quite necessary.  Unix pure user-land clients might be able to do
without IDENTIFIER_GROUP, but clients that want chown/chgrp/getfacl/
setfacl to work will need IDENTIFIER_GROUP.

> defined but dead bit. That's what I say

I hope they don't.

Nico
--

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Wed, 2 Nov 2005 19:03:04 -0800

I dunno, Trond. I think Nico makes a good point.
I'm thinking of scenarios where organizations merge
operations. I don't think UNIX or NT has a pain free
story. It's a fair question. Your answer may turn out
to be the only workable answer. I think it merits a
little rubbing of brain cells, though.

	-gww

> Trond Myklebust
> Sent: Wednesday, November 02, 2005 6:35 PM
> To: Nicolas Williams
> Cc: Gordon Waidhofer; [email-masked]; Lisa Week
> Subject: Re: [nfsv4] New I-D: draft-falkner-nfsv4-acls-00
> 
>

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Wed, 2 Nov 2005 19:24:10 -0800

> namespaces in a Windows domain would break Windows, if you could pull it

I think we violently agree on this.

> you'll be able to tell which it is by looking it up in the directory.

And if the AD lookup disagrees with IDENTIFER_GROUP, then what?
Probably best to ignore IDENTIFER_GROUP and believe the AD server.
So why IDENTIFIER_GROUP at all?

> setfacl to work will need IDENTIFIER_GROUP.

I'm not sure that's true.

	chfacl gww@acme=rw staff@acme=r file

Are you suggesting that the user grok flags or
something that reflect IDENTIFER_GROUP?

All in all, I can see the motivation for IDENTIFER_GROUP
because of UNIX legacy. But UNIX (POSIX ACLs) has problems
with cross-domain ACEs. It's something NT SIDs handle
pretty well. NFSv4 who strings come mighty close to SIDs.
As UNIX systems address cross-domain ACE issues, I can
see IDENTIFIER_GROUP becoming unecessary.

Regards,
	-gww

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 02 Nov 2005 22:28:27 -0500

> can be extended to deal with UID/GID<->SID mapping.

I'm sure it can, but AFAICS it requires you to allocate local uids and
gids for each and every one of those remote usernames and groupnames
that need to be represented in ACLs.

That is the precise issue that we're trying to avoid.

(then there is the whole issue of relying on yet another side band
protocol)

Cheers,
  Trond

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 2 Nov 2005 21:56:48 -0600

> I think we violently agree on this.

Good.  It's a start :)

> And if the AD lookup disagrees with IDENTIFER_GROUP, then what?

Lookup of what?  Name?  In that case, on SETATTR -> server fails the op,
on GETATTR -> client replaces with "nobody" or "nogroup" and complains
or returns an error to the app, or panics :)

> So why IDENTIFIER_GROUP at all?

See above.  I don't propose ignoring IDENTIFER_GROUP.

> something that reflect IDENTIFER_GROUP?

In traditional Unix the user MUST know whether something's a user or
group and use chown or chgrp accordingly.

With POSIX draft ACLs that is still true.  I don't know what 'chfacl' is
or what it's syntax is, but the POSIX draft ACL setfacl(1) command
absolutely requires that the user know a priori whether an entry is to
refer to a user or a group.  This should be abundantly clear from the
man page (you can see the man page for setfacl(1) in Solaris at
http://docs.sun.com/).

> pretty well. NFSv4 who strings come mighty close to SIDs.

Unix has a flat UID and GID namespace, and, traditionally, a flat user
and group *name* namespace.  But flat UID/GID namespaces need not imply
flat user/group name namespace -- my I-D on cross-domain ID mapping is
all about that.

> see IDENTIFIER_GROUP becoming unecessary.

UIDs and GIDs will NOT go away.  Too many apps depend on them, too many
system calls and library functions deal in them.  They cannot disappear
in one day.  The headache, if you see it that way, will just not go
away.

Given a lemon, make lemonade: ID mapping is the way to deal with flat
UID/GID namespaces.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 2 Nov 2005 22:01:17 -0600

> that need to be represented in ACLs.

On demand as they are needed, not all at once nor as they are created.

> That is the precise issue that we're trying to avoid.

You can't avoid ID mapping if you wish to remain compatible with the
many, many Unix applications that deal in UIDs and GIDs and yet support
cross-domain user/group references.

> (then there is the whole issue of relying on yet another side band

This s a very small bit of additional infrastructure in environments
that already depend on quite a lot of infrastructure.  If the choices
are: break compatibility, give up, or add a bit of infrastructure, then
the right choice is clear.  (You can also add a lot of infrastructure,
namely multiple directories and directory synchronization.)

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 2 Nov 2005 22:12:08 -0600

> vary, but users are unitary.

I meant to continue this...

For clients the distinction is an UI matter: so that users can make this
distinction.

Servers need to make this disctinction only if their filesystem format
and/or internal ID system requires it (e.g., as Unix/POSIX does).

Administrators are a subset of users, and they care about this
distinction for the same reason.

Users/admins care about this distinction for ACL mgmt simplicity: ACLs
with many user ACEs are difficult to maintain for as users join/leave an
organization or sub-organization, but ACLs with only group ACEs might
only need changing when an organization is re-structured; this pushes
user join/leave/move operations to the directory, where they belong.

Cheers,

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 02 Nov 2005 23:13:08 -0500

> little rubbing of brain cells, though.

...and if the organisations in question happen to have conflicting
uid/gid allocations for those usernames (I know - this is really really
unlikely), this won't cause ACL mapping problems?
I really don't see the problem here. If the organisations merge, then
the idmapper on the server can surely be made to alias oldname@oldorg to
newname@neworg and hence make everything transparent?

The whole question is what do you do with those foreign ACEs for which
you do _not_ already have a local uid/gid mapping.

Cheers,
  Trond

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 2 Nov 2005 22:17:29 -0600

> newname@neworg and hence make everything transparent?

ID mapping provides a solution, yes, though in my view ID mapping must
map between internal ID namespaces, not between external representations
(i.e., names).

> you do _not_ already have a local uid/gid mapping.

If you can't map them, reject them; I think you can map though -- see my
I-D, Samba, Cygwin, and probably others for theory/proof.  Storing names
in ACLs on disk is not the answer, at least not a good one :)

Nico
--

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Wed, 2 Nov 2005 21:13:14 -0800

> in ACLs on disk is not the answer, at least not a good one :)

That's a legacy friendly answer. And that's OK.

I'm almost back to thinking that saving the ACE who strings
to disk is the right answer. I need to think it through again.

I'm thinking about tar(1) balls sitting on the shelf.
The original tar format saved uid/gid as octal strings.
Later that was extended to save user and group names.
Those names are unqualified -- the domain name is not
part of it. It's reasonable to expect tar 'x' extensions
to hold NFSv4 ACLs. Shucks, APIs (acl(2) and getxattr(2))
are already being contemplated to take that view. If tar
using 32-bit UIDs/GIDs gave way to string names, what's
so weird about seeing that sort of trend continue? The
next step is qualified (includes domain) names and ACLs
in the tar(1)-ball.

Suppose I've got 837 pounds of tape on the shelf with [email-masked].
Then there's a merger. I have to have a story for [email-masked]
to still work even if I switch to being [email-masked].

If we have to find a way to live with large collections of
offline storage, the same approach will work for online
storage, too.

Nico's perch is pragmatic. How do we make NFSv4 work
well today? How do we handle -- or at least fake really
well -- support of cross-domain users and groups? The
traditional UNIX file model makes this awkward, and so
there is no good answer. By that, I mean nobody would
build a system from scratch to work that way: 32-bit
IDs stretched with all kinds of mapping mechanisms
to support cross-domain ACEs.

Trond is contemplating the next turn of the crank.
Saving the who strings is entirely feasible. It
handles cross-domain ACEs quite nicely without
dependence on a fallible server.

I'm not so much suggesting that things should go toward
an NFSv4-centric file model. Rather, I'm suggesting that
they are going to. Existing APIs, manual pages, documents,
etc, aren't going to hold all that back. Trond will implement
NFSv4 ACL who strings native to a file system. It will work.
And, indeed, I think it will be found to be quite agreeable.
Certainly there will be hitches, but it or something very
close to it will prevail.

I think the only mistake that could be made in all
this is to assume that the UNIX model of UIDs/GIDs,
distinct user/group name spaces, and even credentials
(setgroups(2)) are inviolate. They will change.

And change is challenging. And fun. And what we get
paid for. So all is as it should be :)

Regards,
	-gww

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Nov 2005 10:29:48 -0600

> That's a legacy friendly answer. And that's OK.

Which?  ID mapping or storing strings as ACE subjects?

> next step is qualified (includes domain) names and ACLs

Names are fine for short-term use, not fine for long-term use.  I've
explained why.

> to still work even if I switch to being [email-masked].

Suppose your tapes use a different format.

> offline storage, the same approach will work for online

Not quite -- people deal differently with online and offline storage.
Having to cleanup on restore after username changes is one thing, but
having to cleanup online storage after username changes is another.  The
difference is one of degree, but a large difference of degree.

> well -- support of cross-domain users and groups?

ID mapping doesn't fake support for cross-domain users and groups.

>                                                   The

This is true.  If I were starting from scratch I'd use something like
SIDs (i.e., not names, but internal identifiers).

> dependence on a fallible server.

It's feasible.  It's also painful.

> close to it will prevail.

Here's a question: given that you (Trond) is willing to store strings,
why not store SIDs and be done?

> (setgroups(2)) are inviolate. They will change.

They won't go away.  You can add replacements, if you like, but the
originals will stick around for a long, long time.

> paid for. So all is as it should be :)

We get paid to change things for the better, and to manage change.
Mostly it's fun also :)

Cheers,

Nico
--

---

From: Mike Eisler <[email-masked]>
Date: Thu, 3 Nov 2005 08:45:28 -0800 (PST)

--- Nicolas Williams <[email-masked]> wrote:

> Name-based authorization is...  Bad.  What happens when users 

This is like saying:

   share -o rw=hostname /export

is bad and

   share -o rw=10.1.2.3 /export

is good.

> renamed?  That, BTW, happens very, very often.

Do you have references to the frequency that this happens?

I think what happens much more often are organizational
mergers and acquisitions where user names rarely conflict, 
but user id numbers in the passwd map do conflict. And that 
is a total hassle. Every inode in each victim's data set has 
to be altered.

Storing a name instead of a uid number minimizes the
odds of the need to touch inodes.

Also, in a multiprotocol world, it makes little difference what
the underlying native file system format is for storing user
identifiers is, but if the identifier is a merely a 32 bit value,
one will find that very limiting. Windows uses SIDs; they don't
fit in 32 bits. Whereas string names  at least have a hope of
being a canonical form for Windows, UNIX, Kerberos, AD,
public key certificates, etc. 

If most of the NFS traffic is version 4, then
strings as the native format beat integers.

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 03 Nov 2005 11:49:07 -0500

> why not store SIDs and be done?

Here's a better question: if SIDs are more stable than usernames, why
aren't they being used in the on-the-wire protocol between client and
server?

The protocol doesn't force you to use usernames. All it says is that it
must be a UTF-8 string in the form user@domain and that there must exist
a mapping into security principals.

Cheers,
  Trond

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Nov 2005 11:13:41 -0600

> aren't they being used in the on-the-wire protocol between client and

Who says they aren't?  Oh, you're talking about NFSv4 ;)

So, NFSv4 appears to have struck a compromise to avoid having to use
platform-specific internal ID forms, and that compromise is to use
strings on the wire, a fine compromise, IMO.  NFSv4 does not require
that you *store* strings though.

> a mapping into security principals.

I'm pretty sure that if you resorted to base-10 encoded UIDs/GIDs@domain
that your implementation won't interop.  I think most if not all other
implementors really expect user/group names on the wire.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Nov 2005 11:26:02 -0600

>    share -o rw=10.1.2.3 /export

What's bad about any one kind of identifier is how often it might
change.

IP addresses are liable to change more often than hostnames, but
usernames are liable to change more often than UID assignments.

Also, user interface have got to deal with names.  That's because most
users can't deal with meaningless-looking numbers.  So even if IP
addresses were more stable than hostnames the share command should still
be used with hostnames, and let the access control be done based on IP
addresses (oh wait, that is how it's done already! :) :)

Most organizations have procedures in place such that internal
user/group IDs are never re-used.

> Do you have references to the frequency that this happens?

Only my memory from my previous life as a sysadmin.  I recall marital
status changes as being the most common source of username changes, but
not the only one.  Often usernames are created based on formulaic
policies (e.g., "first six letters of the last name, plus the first and
middle initial") and you'd be surprised how many, er, funny usernames
are generated that way, often offensive to the user in question if not
also to others.  Typos account for most of the rest -- lots of people
have names with difficult spelling.

Soon, as we internationalize the user/group namespace we'll also see
folks wanting the umlauts and accents, and whatnot in their usernames.

> is a total hassle. Every inode in each victim's data set has 

Oh usernames (and especially, group names) will conflict then too, but
that's not the main problem -- the flat UID/GID is, as you note.

ID mapping gets you out of that.

> odds of the need to touch inodes.

No, the domain name does that, not the name.

BTW, domain names change too.  In my previous life as a sysadmin I
worked on several mergers and several corporate renaming excercises.

> public key certificates, etc. 

Windows uses 32-bit RIDs to identify users and groups in a given domain;
it uses three 32-bit RIDS to identify domains.  Altogether that makes
for 32-bit user/group RID @ 96-bit domain ID.

> strings as the native format beat integers. 

I don't agree.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 03 Nov 2005 12:25:03 -0500

> that you *store* strings though.

Of course not. That was never the question being discussed.

The question being discussed is: "Is it a good idea to store strings?"

> implementors really expect user/group names on the wire.

That is not the fault of the protocol, but an issue of implementation.
The existing implementations must change in order to do cross-realm
mapping anyway.

Cheers,
  Trond

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Nov 2005 11:33:44 -0600

> The question being discussed is: "Is it a good idea to store strings?"

My answer to which you already know.

> That is not the fault of the protocol, but an issue of implementation.

No, it's not.  Implementors have to know what to do with an on-the-wire
representation of users and groups.

Implementors know how to lookup names<->internal ID forms and so that's
what they do with NFSv4 user/group representations: they lookup the
internal IDs corresponding to names on the wire -- they don't know to
that some representations are already internal IDs of this or that form.

It is crucial for interop that a representation of users and groups on
the wire be agreed upon, and one has been agreed upon: they are names.

> The existing implementations must change in order to do cross-realm

But they can do that with ID mapping, which can happen entirely outside
the context of NFSv4.

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 03 Nov 2005 12:52:36 -0500

> the wire be agreed upon, and one has been agreed upon: they are names.

Then the conclusion is that you cannot change user names, and we're
right back to where we started.

Cheers,
  Trond

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Nov 2005 11:58:44 -0600

> right back to where we started.

Not quite.  You can't safely reuse names while clients might still be
doing "get acl, change acl, set acl" -- that's certain, but you can't
say that once created a name simply cannot change for that is certainly
not what users expect nor what they're used to (when a director tells
you to change their username, something that's not obviously
objectionable, you do it).

Nico
--

---

From: Peter Astrand <[email-masked]>
Date: Thu, 3 Nov 2005 19:53:08 +0100 (MET)

> in ACLs on disk is not the answer, at least not a good one :)

Nicolas, I fully agree with you. Storing the name strings in the file
system feels very wrong. I would really prefer a solution where the native
format is used - ext3 and ufs file systems should store uids/gids in the
ACLs, Windows file systems should store SIDs.

The protocol should allow for rejecting names for which you do not have a
mapping. This strategy will, however, allow for servers to allocate
uids/gids/SIDS on the fly when necessary.

Btw, these issues with names versus numbers have been discussed earlier on
this list. In particular, the thread starting with
http://www.nfsv4.org/nfsv4-wg-archive-dec-96-jan-03/3367.html might be
worth a read for those that are not yet convinced :-)

/Peter Åstrand <[email-masked]>

---

From: Mike Eisler <[email-masked]>
Date: Thu, 3 Nov 2005 20:09:40 -0800 (PST)

> addresses (oh wait, that is how it's done already! :) :)

Actually access control isn't IP based in at least two NFS servers I know of. Instead, the server
reverse maps the client's
IP address to a name and string compares the name to what is
in the rw=, ro= and/or root= list. But I digress.

> status changes as being the most common source of username changes, but

At most places I've worked, users pick their login names, and
if they include a surname, or use initials that include a 
surname, tough luck if their marital status changes; they are
stuck with it. Too many systems, particularly in HR, depend
on the user name staying the same.

> are generated that way, often offensive to the user in question

First those are bad policies, so perhaps storing
user names in inodes would be a way to dissuade bad practices.
Second, that's something that something that happens
early user's career at the organization. Sam Tupid joins the
company and finds a note attached to his cube: "Welcome to
Idiot, Inc., [email-masked]". Sam has his login name changed
the same day. Not a great deal of data is created because Sam
spends most of his first few days screaming at his boss, the HR
department, and the IT department.

So I'm not seeing evidence that user name changes for users
with large data sets occurs often.

> folks wanting the umlauts and accents, and whatnot in their usernames.

Unless users constantly migrate to other countries that 
domesticize names and so are constantly adding and removing
their umlauts and accents, it will be one time deal. So
that's not an argument for not using user names on 
file system metadata.

> ID mapping gets you out of that.

How? If alice and bob have the same uid (2000), how does
ted, when he does a getattr for a /home/alice/.cshrc 
get back "alice" in the NFSv4 results and not "bob".

> No, the domain name does that, not the name.

Only if one picks login names that are bound to conflict.
In my case, once I abandoned "mike" as a login name,
I've never had my first choice of a login name be unavailable, but my uid, except when moving from
a larger company to
a smaller company has always conflicted. I've noticed this
where I work now ... many of the people I work with had the same
login name when I worked with them 5, 10, 20 years ago at
different companies.

> for 32-bit user/group RID @ 96-bit domain ID.

Yes you've explained why SIDs don't fit in 32 bits. Thus
there is a requirement for identifiers stored in file system
metadata that exceed 32 bits. We can store 32 byte SIDs which
aren't canonical, or strings that will for the local domain
case average under 32 bytes in length and still be canonical. 

Keeping names and not numbers on the metadata prevents
users from seeing and creating files owned by "nobody".

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Thu, 3 Nov 2005 21:36:49 -0800

I read the email Peter pointed at. I pondered.
Here's what I came up with.

I'm firmly back in the strings-as-account-IDs camp.

On an NFSv3 server, I can do something like this:

	chown 1234567 file

And it works. The server does not audit the UID to be
sure it is valid. Later, if at some point UID 1234567
is valid (shows up in a credential), access control
works as one would expect.

So, I don't see intrinsic merit it mapping users and
groups to 32-bit IDs. Suppose I want to use 17-bit IDs?
How about 27-bit IDs? How about 270-bit IDs? How about
2700-bit IDs? In other words, don't get hung up on 32.
Shucks, it wasn't so long ago that UIDs and GIDs
were 16 bits.

Generating an N-bit ID on-the-fly is much like the
chown example above. So, suppose I'm on an NFSv4
server and this works using nothing but string IDs:

	chown [email-masked] file

OK, the N in N-bits is larger than 32. So?
I have a perfect story for generating it on the fly
and no inconvenience associated with a server having
to reject it. Later, if at some point ID [email-masked]
is valid (shows up in credentials) access control works as
one would expect.

This is somewhat the expectation that has been set
with users of NFSv2/3 (chown 1234567 works
without having to first define UID 1234567).

The impetus of this latest discussion was whether
IDENTIFIER_GROUP was required. It is practical because
of UNIX legacy. The same can be said of trying to
make a case for 32-bit IDs. Mapping servers, et al,
will work. But it does *NOT* have intrinsic merit.

Now, let's ignore the traditional AUTH_SYS credentials
for a moment. Suppose credentials are simply an unordered
list of string IDs. Suppose when I log in I get credentials:

	[email-masked] [email-masked] [email-masked] [email-masked]

The NFSv4 ACLs will work just fine:

	match (principle, ace_who) {
		for ID in principle
			if ID == ace_who
				return TRUE;
			fi
		end for
		return FALSE;
	}

There is no distinction between users and groups. This is what
I was driving at with my "not a dumb question" to Nico. What
is the value of distinctions supported by IDENTIFIER_GROUP?
Simply, it is that UNIX systems have distinct name (string)
and 32-bit-ID (UID/GID) spaces. IDENTIFER_GROUP is a 33rd-bit
needed by UNIX systems.

Again, as a practical matter, IDENTIFIER_GROUP and
endeavoring to make UNIX 32-bit UIDs and GIDs work
is fine. I'd rather not see it taint the NFSv4 protocol
anymore than necessary. I can accept that IDENTIFIER_GROUP
is a bit of a necessary wart at least for a few years.

That said, I think what Trond is up to is pretty cool
and will likely work out fine. Perhaps even ideal.

This has been a fun discussion. I started (at the
NAS conference) thinking something like SIDs would
be the right approach. Then Trond made a case for
string IDs. I was so sure that string IDs were a good
idea. Then I got wobbling when Nico asked about changing
login names. Then Peter's email was, I believe, suppose
to make a strong case for 32-bit IDs (or SIDs) but
instead made me a string-ID believer again.

Regards,
	-gww

> Peter Astrand
> Sent: Thursday, November 03, 2005 10:53 AM
> To: Nicolas Williams
> Cc: [email-masked]