Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

On Jul 9, 2006, at 10:22 AM, Andreas Gruenbacher wrote:

> On Saturday, 8. July 2006 05:45, Sam Falkner wrote:
>> On Jul 7, 2006, at 5:55 AM, Andreas Gruenbacher wrote:
>>> On Monday, 3. July 2006 23:10, Andreas Gruenbacher wrote:
>>>> Hello,
>>>>
>>>> I have been thinking about the problems of interaction between
>>>> NFSv4 ACLs and POSIX, and particularly about the issue of masking
>>>> permissions through chmod and after creating files or directories.
>>>
>>> Here is a follow-up after some personal feedback from Sam. I
>>> believe that draft-ietf-nfsv4-acls-00 is not ready to become part  
>>> of the
>>> NFSv4 Minor Version 1 RFC: some assumptions are not correct from  
>>> a POSIX
>>> point of view, and the way how chmod and file create modes are  
>>> applied to
>>> NFSv4 ACLs is weak and not guaranteed to be correct.
>>
>> I disagree -- see below.
>
> Here are some facts to back my points: Let's assume that a file  
> inherits the
> following ACL when being created (I am using ^(...) here with the  
> meaning of
> "all bitflags except ..."):
>
> 	OWNER@:READ_DATA/WRITE_DATA::ALLOW
> 	OWNER@:^(READ_DATA/WRITE_DATA)::DENY
> 	GROUP@:READ_DATA::ALLOW
> 	user@domain:READ_DATA/WRITE_DATA::ALLOW
> 	GROUP@:^READ_DATA::DENY
> 	user@domain:^(READ_DATA/WRITE_DATA)::DENY
> 	EVERYONE@:READ_DATA::ALLOW
>
> This acl is "well structured" in the POSIX sense: OWNER@ will only  
> get the
> owner permissions and none of the other permissions, user@domain  
> and GROUP@
> will only get the permissions intended for them, and only others  
> (neither
> OWNER@ nor user@domain nor GROUP@) will get EVERYONE@ permissions;  
> in other
> words, the acl is even correct for non-monotonic permissions.
>
> According to section 5.1 of draft-ietf-nfsv4-acls [1], the  
> resulting file mode
> permission bits for this acl shall be rw-r--r--. After a chmod or a  
> file
> create, alternate file access control mechanisms must be disabled  
> and only
> additional file access control mechanisms may remain active.  
> According to
> POSIX, additional file access control mechanisms require that no  
> user may be
> granted more permissions than the respective file classes permit.  
> In this
> case, user@domain clearly is not in the File Owner Class.  
> (According to
> POSIX, user@domain must be in the File Group Class.) The  
> user@domain user is
> granted WRITE_DATA though, which is *incorrect* from a POSIX point  
> of view.
>
> Next, let's assume than an ACL contains the following pair of user- 
> provided
> entries:
>
> 	GROUP@:WRITE_DATA::DENY
> 	GROUP@:READ_DATA::ALLOW
>
> Clearly the user's intention is to deny WRITE_DATA access to  
> GROUP@. The
> algorithm to apply a mode to an existing ACL will remove the  
> WRITE_DATA bit
> from the GROUP@:WRITE_DATA::DENY entry when a chmod(..., 0770) is done
> though. This is counter to the user's intention, so I would call  
> that *wrong*
> as well. It also violates the principle of least surprise. There  
> really is no
> safe way to tell user-provided ACL entries from artificially made  
> up ACL
> entries.
>
> draft-ietf-nfsv4-acls is missing a clear classification of ACL  
> entries into
> the File Owner, File Group, and File Other classes. Every ACL entry  
> must be
> in one of the three classes in order to compute appropriate file mode
> permission bits when setting an ACL, and after inheriting  
> permissions. This
> classification also determines which effect chmod will have on an ACL.
>
> So draft-ietf-nfsv4-acls is *incorrect* and *wrong* from a POSIX  
> point of
> view, while my alternative proposal is correct, apart from being  
> simpler to
> implement. I hope that my emails and some background reading (like  
> the file
> access related parts of the POSIX definitions volume [5], a paper that
> explains POSIX ACLs and how they are implemented on Linux [6], and  
> perhaps
> 1003.1e draft 17) will convince you about that.
>
> Note that in traditional POSIX, permissions from multiple file  
> classes will
> never accumulate: each user always is either granted the File Owner
> permission bits, the File Group permission bits, or the File Other  
> permission
> bits. (Additional file access control mechanisms may further limit the
> permissions granted, and alternative file access control mechanisms  
> may
> further limit or extend the permissions granted.) Permissions from  
> multiple
> acl entries accumulate in the NFSv4 ACL model though, and so unless  
> an acl is
> "well structured" in the above sense, permissions from multiple  
> classes may
> accumulate.

Yes, permissions may accumulate, but in the design in the minor  
version doc, after a chmod, any permissions that go beyond the mode  
bits being set will be disabled.  This is done via the algorithm in  
section 3.16.6.3 -  "Applying a Mode to an Existing ACL".  This makes  
sure that the permissions (ACE4_READ_DATA/ACE4_LIST_DIRECTORY,
ACE4_WRITE_DATA/ACE4_WRITE_DATA, ACE4_APPEND_DATA/ 
ACE4_ADD_SUBDIRECTORY and ACE4_EXECUTE... which is what the mode  
defines) that accumulate will NOT go beyond the mode bits being set.

>
>>> I will first try to clarify some of the points I tried to make in
>>> the previous posting and point out deficiencies in
>>> draft-ietf-nfsv4-acls-00. Then I will propose an alternative  
>>> design which
>>> is more correct than introducing DENY entries to mask  
>>> permissions. (As a
>>> bonus, it is easier to implement. too.)
>>>
>>>> On a UNIX system that supports NFSv4 ACLs natively, I think we
>>>> should try to accept as wide a range of NFSv4 ACLs as possible,  
>>>> but we
>>>> must make sure that we can preserve POSIX semantics. In  
>>>> particular, this
>>>> means that ACLs may contain ACEs for users other than OWNER@,  
>>>> GROUP@, and
>>>> EVERYONE@, and that chmod(2) must continue to provide the same  
>>>> kinds of
>>>> guarantees as without NFSv4 ACLs.
>>>>
>>>> I am assuming here that NFSv4 ACLs shall be an additional rather  
>>>> than an
>>>> alternate file access control mechanism in the POSIX sense:  
>>>> Alternate
>>>> file access control mechanisms must ``be enabled only by  
>>>> explicit user
>>>> action, on a per-file basis by the file owner or a user with the
>>>> appropriate privilege'', and must ``be disabled for a file after  
>>>> the file
>>>> permission bits are changed for that file with chmod( )''  
>>>> according to
>>>> POSIX. In other words, newly created files or directories would  
>>>> have
>>>> alternate file access control mechanisms disabled. This would  
>>>> render
>>>> NFSv4 ACLs essentially useless for UNIX processes, because they  
>>>> would
>>>> almost always be disabled, and would only work for remote  
>>>> processes until
>>>> a POSIX process chmods a file or creates a directory, which  
>>>> wouldn't get
>>>> us very far.
>>>
>>> As Sam pointed out, a subset of NFSv4 ACLs maps to an additional  
>>> file
>>> access control mechanism, while the rest goes beyond that, and  
>>> therefore
>>> is an alternate file access control mechanism.
>>
>> Yes -- ALLOW ACEs are alternate file access control, and DENY ACEs
>> are additional file access control.
>
> This classification makes no sense, and it also does not match what  
> you
> propose in section 5.3 of draft-ietf-nfsv4-acls, either: there are  
> acls that
> contain ALLOW entries which are still only an additional file  
> access control
> mechanism, so we really need to classify them as an additional file  
> access
> control mechanism in order to avoid having to disable them during  
> chmod or
> when inheriting permissions.

We clearly have a disagreement what "additional" and "alternate" file  
access control mechanisms mean to NFSv4 ACLs.

Without these fundamental things, we will never be able to reach  
consensus.  So lets try to up-level the discussion and see if we can  
get agreement on what the meanings of these two access control  
mechanisms are in the context of NFSv4...

I know this has been iterated over and over again, but bear with  
me...  hopefully this will give you a better idea of where we're  
coming from.

POSIX defines Additional Access Control Mechanism as follows:
"An implementation-defined mechanism that is layered upon the access  
control mechanisms defined here, but which do not grant permissions  
beyond those defined herein, although they may further restrict them."

POSIX defines Alternate Access Control Mechanisms are as follows:
"An implementation-defined mechanism that is independent of the  
access control mechanisms defined herein, and which if enabled on a  
file may either restrict or extend the permissions of a given user.  
IEEE Std 1003.1-2001 defines when such mechanisms can be enabled and  
when they are disabled."

So, the question that comes to my mind when reading that text is:  
What does it mean when they say "access mechanisms defined herein" in  
both of those definitions?  Well, the access mechanisms defined in  
the POSIX spec are the "File Access Permissions", right?  So, can we  
agree that "access mechanisms defined herein" would be the "File  
Access Permissions"?

Okay, the description of "File Access Permissions" says that "The  
standard file access control mechanism uses the file permission bits..."

So, what are the file permission bits?  They are read, write, execute/ 
search for the File Owner Class, File Group Class and File Other Class.

So, to put this together, Additional access control mechanisms are   
the ability to further restrict the read, write, execute/search  
permissions for the File Owner Class, File Group Class and File Other  
Class.  And, Alternate access control mechanisms are the ability to  
either restrict or extend the read, write, execute/search permissions  
for the File Owner, Group and Other Class.

Now, to classify NFSv4 ACLs into Additional and Alternate access  
control mechanisms...
Since we are only controlling the read, write, execute/search  
permissions, the only permissions we should classify in NFSv4 ACLs  
are the access mask bits that intersect with the file permission bits  
as defined by POSIX.  And for NFSv4 that means the following access  
mask bits are of interest:
ACE4_READ_DATA/ACE4_LIST_DIRECTORY
ACE4_WRITE_DATA/ACE4_WRITE_DATA, ACE4_APPEND_DATA/ACE4_ADD_SUBDIRECTORY
ACE4_EXECUTE.

(Actually, this is where the existing draft-ietf-acl-00 proposal is  
confusing.  It doesn't come right out and say this.  In the write up  
we had the assumptions that this was clear, but I know that it needs  
to be further specified.)

So, now in the NFSv4 ACL sense, Alternate access control mechanisms  
are used to further extend and Additional access control mechanisms  
are used to further restrict the following access mask bits:
ACE4_READ_DATA/ACE4_LIST_DIRECTORY
ACE4_WRITE_DATA/ACE4_WRITE_DATA, ACE4_APPEND_DATA/ACE4_ADD_SUBDIRECTORY
ACE4_EXECUTE.

How would one extend those access mask bits (Alternate)?  By putting  
them in an ALLOW ACE.
How would one restrict those access mask bits (Additional)?  By  
putting them in a DENY ACE.

As far as the other access mask bits...they aren't covered by the  
POSIX File Access Permissions so do they need a classification?  No,  
not really.  (More on this below...)

> If ALLOW ACEs were alternate in general, then we
> would have to disable them all after a chmod, and I think we agree  
> that this
> would make ACLs practically useless in combination with POSIX.
>
> The only classification that makes sense is by the permissions that  
> an ACL
> grants.

I would agree with that, but don't go putting further restrictions on  
us than POSIX defined in the first place.  As said before POSIX only  
defines what should happen with regard to the access control  
mechanisms that layer on top of or extend the *file permission  
bits*.  See more below.

> You have given an example of an ACL that clearly is an additional
> file access control mechanism only. With this kind of  
> classification, a
> significant subset of NFSv4 ACLs can be treated as an additional  
> file access
> control mechanism, which makes them actually useful even when POSIX  
> systems
> and Windows (or other systems with NFSv4 ACLs or similar) interact  
> and both
> change ACLs.

The thing that is still out there is that if you classify ACEs with  
ACE4_READ_DATA, for example, as an additional access control  
mechanism, you will never be able to give a arbitrary user or group  
the ACE4_READ_DATA permission without having the File Class that it  
belongs to also have at least those permissions.  That seems broken  
to me.

>
>>> It is important to understand how POSIX defines additional file
>>> access control mechanisms:
>>>
>>> [] 3.4 Additional File Access Control Mechanism
>>> [] An implementation-defined mechanism that is layered upon the
>>> [] access control mechanisms defined here, but which do not grant
>>> [] permissions beyond those defined herein, although they may  
>>> further
>>> [] restrict them.
>>>
>>> In other words, when a file has just been created and after chmod,
>>> the file mode permission bits define an upper bound to the  
>>> permissions
>>> granted to anyone on the system, and nobody has additional  
>>> permissions.
>>> Additional permissions (as an alternate file access control  
>>> mechanism) may
>>> be enabled explicitly, but the next chmod must disable them again.
>>
>> The use of the word "Additional" is confusing in the above
>> sentence.  :-)  I think you mean "more", or similar, but "Additional"
>> has a very specific meaning which (I think) isn't what you mean.
>
> I indeed meant more permissions as in additional mask bits granted,  
> as opposed
> to an additional file access control mechanism in the sense how  
> POSIX defines
> this term.
>
>>> We can classify the permissions that NFSv4 ACLs grant into  
>>> additional and
>>> alternate mechanisms as follows: everything covered by the POSIX
>>> read/write/execute permissions (such as ACE4_READ_DATA, but also
>>> ACE4_APPEND_DATA) is additional, while everything beyond that  
>>> (such as
>>> ACE4_WRITE_OWNER) is alternate.
>>
>> Note well: this is quite different from draft-ietf-nfsv4-
>> minorversion1-03.txt, i.e. this is an alternate proposal.
>
> Yes, this is a different approach of classifying NFSv4 ACLs into  
> additional
> and alternate file access control mechanisms, which complies to  
> POSIX as well
> as to the current NFSv4 RFC. It conflicts with draft-ietf-nfsv4- 
> acls, and by
> implication with draft-ietf-nfsv4-minorversion1-03 [4], which  
> includes the
> same text.
>
> Note that draft-ietf-nfsv4-acls is inconsistent in itself: the  
> algorithm in
> section 5.3 restricts which permissions an ACL grants by masking  
> permissions
> (which implies that you are classifying by permission as opposed to  
> turning
> off all ALLOW entries),

I give you this.  The wording about the classification of ACEs in  
draft-ietf-nfsv4-acls is not quite sufficient.  As I've said before,  
It makes some important assumptions, but isn't clear as to what those  
are.  It doesn't map to what the algorithm specifies.  With that  
said, it was not meant to be misleading in any way.

As documented in the algorithm definition in section 3.16.6.3 -  
"Applying a Mode to an Existing ACL" of the minor version doc, the  
following is a clarification of the classification:

ALLOW ACEs with ACE4_READ_DATA/ACE4_LIST_DIRECTORY, ACE4_WRITE_DATA/ 
ACE4_ADD_FILE, ACE4_APPEND_DATA/ACE4_ADD_SUBDIRECTORY, and  
ACE4_EXECUTE access mask bits are Alternate security mechanisms.   
These access mask bits will be disabled upon chmod.

DENY ACEs with those access mask bits are Additional access control  
mechanisms.  These access mask bits will be left unchanged  after a  
chmod, unless, as described in 3.16.6.3 it is one of the special  
identifiers, OWNER@, GROUP@, EVERYONE@.

All other access mask bits listed below are outside of the access  
control mechanisms specified by POSIX and are therefore unclassified  
and unrestricted:
ACE4_READ_NAMED_ATTRS
ACE4_WRITE_NAMED_ATTRS
ACE4_DELETE_CHILD
ACE4_READ_ATTRIBUTES
ACE4_WRITE_ATTRIBUTES
ACE4_DELETE
ACE4_READ_ACL
ACE4_WRITE_ACL
ACE4_WRITE_OWNER
ACE4_SYNCHRONIZE

This means that if an ACE defines one of those access mask bits, the  
access granted or denied will remain unchanged after a chmod.

> while section 14.4 says that "the ALLOW type of ACE
> is considered to be an alternate file access control mechanism  
> because it can
> further extend the permissions of a user".
>

Thoughts?

Thanks,
Lisa