Subject: Re: Speaking of ACLs

From: Jim Rees <[email-masked]>
Date: Wed, 10 Apr 2002 17:37:53 -0400

I would be strongly opposed to changing the spec now to add Microsoft's odd
distinction between inherited and non-inherited acls.  I would also argue
that no change is needed, because a client already has a way to determine
whether an ace was inherited or not, and a way to specify what order the
aces appear in the acl.

Making acls any more complicated than they already are is a bad idea.

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 10 Apr 2002 18:00:09 -0400

Concur strongly with the below.  This is supposed to be vendor-neutral
and already too much Microsoft-centric complications are in NFSv4.
We don't need any more vendor-specific gorp in an already too complex
spec.

Ran

---

From: "Dan Trufasiu" <[email-masked]>
Date: Wed, 10 Apr 2002 18:18:21 -0400

I know that I try the same thing in the past and I make some people unhappy.
I will try again. I learned in school that a protocol has to described an
interaction between a client and a server. Looks to me that now every time
that we run in a problem that require some difficult implementation
decisions we are trying to force a change into the protocol. There are a lot
of proposal for new messages, new flags. I know that we can not release a
broken specification, but adding new stuff will create new problems new
incompatibilities. And we can go this way forever.
Like Jim, I strongly oppose any change in the protocol. Don't try to save a
client that doesn't know what he is doing.

Thanks

Dan

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jim Rees
> Sent: Wednesday, April 10, 2002 5:38 PM
> To: [email-masked]
> Subject: Re: Speaking of ACLs
>
>

---

From: Neil Brown <[email-masked]>
Date: Thu, 11 Apr 2002 10:53:02 +1000 (EST)

> I will try again. I learned in school that a protocol has to described an
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> interaction between a client and a server.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is one of the few relevant comments in what seems to be totally
off-topic thread.  You certainly didn't make me unhappy.

NFSv4 is *NOT* a filesystem.  It should *NOT* make up rules about how
filesystems should work.

What NFSv4 should do (and to a large extent does do) is identify the
largest common set of functionality for client-server interaction, and provide a
protocol that allows communication about that functionality.
And then it should identify areas where communication is need, but
which aren't within that largest-common-set, and allow client and
server to negotiate to find out what is supported, and then to use the
extra discovered commonality.

In the context of ACLs there appears to be very little commonality and
lots of diversity.  NFSv4 should acknowledge that.

About all you can be sure of is a concept of "read-only" and a concept
of "private" meaning that access is restricted in some sense.  There
probably a little bit more commonality that you can find, but it
wouldn't be much.

A server should be able to say "This filesystem uses ACL style X and
can simulate A B and C in that order of preference.".  The client
might know some or all of these and choose one that it wants to work
with.

It may be that every ACL involves a list of ACEs each of which
contains an identity and a number of bits, some with predefined
meaning (read/write/execute/search etc) and some reserved for
different ACL flavours to interpret differently.  It would be
reasonable to specify this level of detail generically in a Network
Filesystem Protocol, but no more.

So a discussion about what particlar ACL schemes should be supported,
and exactly what they mean, and how/when to simulate various schemes
from others might all be on topic.  But discussing how ACL's should
work in some absolute sense seems totally out of place for an
interoperating filesystem protocol.  It belongs in the context of a
particular filesystem implementation, or a particular client API
description.

NeilBrown

---

From: David Robinson <[email-masked]>
Date: Wed, 10 Apr 2002 20:18:11 -0500

> NFSv4 is *NOT* a filesystem.  It should *NOT* make up rules about how

To the contrary, NFSv4 is a filesystem like previous versions
of NFS.  The protocol documents describe not only the bits
on the wire but also the semantics of that should be observed.
How things work is clearly part of the protocol.  As an example,
NFSv2 clearly stated that the result of a write operation
MUST NOT be returned before the data was committed to
stable storage. All of the many pages of text describing
the NFSv4 operations are primarily dedicated to the definition
of the semantics of the NFSv4 filesystem.

The art of an NFS developer is to provide an implementation
that maps the protocol to a local representation to become
a server, and to map the operating system's expected semantics
to protocol operations.

With respect to ACLs, it is very important to define the
visable effects of a set ACL operation as observed by a client
(primarily through the OPEN operation). If server's are
free to provide any arbitrary semantics, the result will
be a lack of consistent semantics between different
server implementations leading to inoperability.

The effects of an NFS client setting an ACL is
completely undefined with respect to another file
system protocol or a local "client" accessing
or changing the ACL.

	-David