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

[Sam Falkner <[e-mail]>]

On Jul 11, 2006, at 4:45 AM, Andreas Gruenbacher wrote:

> On Tuesday, 11. July 2006 08:17, Sam Falkner wrote:
>> On Jul 10, 2006, at 5:50 PM, Andreas Gruenbacher wrote:
>>> On Monday, 10. July 2006 15:29, Sam Falkner wrote:
>>>> 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:
>>>>>
>>>>> 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--.
>>>>
>>>> Your proposal would give this mode: rw-rw-r--.  I think we should
>>>> consider this more carefully.
>>>>
>>>>> 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.
>>>>
>>>> No, it is not granted WRITE_DATA after a chmod().  After a chmod  
>>>> 644,
>>>> there will be a "user@domain:WRITE_DATA::DENY" prepended.  This is
>>>> well defined in the current minorversion1.  So it is not "incorrect
>>>> from a POSIX point of view."
>>>
>>> Now that I look at the example again, I realize that I didn't
>>> define the create mode. With create mode 640 or less permissive,
>>> everything is fine. Let's assume create mode 664 though: then the  
>>> file
>>> mode permission bits will still come out as rw-r--r--, but the  
>>> ACL will
>>> grant WRITE_DATA to user@domain. That's the case I meant, and  
>>> this case is
>>> not POSIX compliant.
>>
>> Wrong.  The file mode permission bits will be rw-rw-r--.  There is no
>> problem with POSIX compliance.
>
> Ah. And why should that be according to draft-ietf-nfsv4-acls-00?  
> Because the
> group file mode permission bits write through to GROUP@ entries,  
> and so the
> rw- group permissions in the create mask elevate the permissions  
> given to the
> owning group in the ACL?
>
> I hope that my reply from Tue, 11 Jul 2006 10:05:21 +0200 made it  
> clear that
> writing through to the GROUP@ entries causes POSIX applications to
> accidentally remove restrictions from an ACL, and so we really must  
> not do
> that. The same argument applies to writing through to OWNER@ and  
> EVERYONE@
> entries, by the way. The "The final six ACEs are adjusted according  
> to the
> incoming mode" section of the algorithm described in 5.3 is a  
> really bad
> idea.
>
>>>>> 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@.
>>>>
>>>> Yes, that *was* the user's intention, at the time the user set the
>>>> ACL.
>>>
>>> Hm... not the best example because GROUP@ is the owning group, which
>>> corresponds to the group file mode permission bits in traditional
>>> POSIX. The problem is more difficult to see in this case, but I  
>>> argue
>>> that the owhning group permissions and the group file mode  
>>> permission
>>> bits are not the same with ACLs: the file group mode permission bits
>>> restrict GROUP@ entries, and all user@domain and group@domain  
>>> entries
>>> in the acl. For the sake of this example, substitute GROUP@ with
>>> user@domain though, and you'll see the problem more clearly: a user
>>> adds an explicit user@domain:WRITE_DATA::DENY entry to an acl which
>>> is followed by a user@domain:READ_DATA::ALLOW entry. After a  
>>> chmod to
>>> 664 for example, this user suddenly has write access. The
>>> user clearly did not intend this to happen.
>>
>> No -- after the chmod, the DENY still stands, unaltered.
>
> Great Sam, you have trapped me with another special case that is  
> there only
> because of those pesky mask DENY entries: "the mask bits are a  
> subset of the
> mask bits of the current ACE" [1].

I trapped you, but not out of malice.  The fact that you fell into  
the trap proves a point.  You tried to give an example as a  
reasonable pair of ACEs that a user would set, and fell into the trap  
of having the design deal with your ACEs correctly.  The design is to  
only manipulate DENY entries if the follow a very specific pattern, a  
pattern that an end-user is unlikely to set.  In other words, the  
design avoids manipulating DENYs unless the DENYs are redundant.

> My point still holds, just that the following ALLOW ACE must have  
> the denied
> WRITE_DATA permission set as well:
>
> 	user@domain:WRITE_DATA::DENY
> 	user@domain:READ_DATA/WRITE_DATA::ALLOW

Yes, there, the chmod would change the DENY ACE.  So if an end-user  
really did say WRITE_DATA:DENY, WRITE_DATA:ALLOW, albeit with other  
bits, then yes, the ACL can change as a result of the chmod.

> Do you *still* disagree?

I don't disagree that the DENY would be changed by a chmod(), but I  
do disagree that it's a major flaw.

I would rather live with the flaw of having redundant user-supplied  
ACEs manipulated upon chmod than to add new file attributes that  
NFSv4.0 clients and servers won't know about.

- Sam

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