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:05 AM, Andreas Gruenbacher wrote:

> On Tuesday, 11. July 2006 07:42, Sam Falkner wrote:
>>>> I think having chmod be functional, i.e. chmod 770 gives write
>>>> permission to the owning group, and an "ls -l" shows "rwxrwx---",
>>>> would be best by far.
>>>
>>> It screws you when you want to give the owning group fewer  
>>> permissions
>>> than other users in the File Group Class. This can be worked  
>>> around by
>>> creating a dummy group with no members, or one group that only  
>>> contains
>>> a single user for each user, and changing the owning group of  
>>> files, but
>>> the owning group already has other defined uses in POSIX (think  
>>> of SETGID
>>> for files and directories), and so it's not desirable and not always
>>> possible to change the owning group to such a dummy group.
>>
>> No -- if you want owning group to have fewer permissions than other
>> users, you're using an ACL.  You use tools that manipulate ACLs.
>
> Sorry, but while this may look like a good idea at first, it  
> doesn't work very
> well. Let's look at an example:
>
> 	OWNER@:READ_DATA/WRITE_DATA::ALLOW
> 	GROUP@:READ_DATA/WRITE_DATA::ALLOW
> 	user@domain:READ_DATA/WRITE_DATA::ALLOW
> 	EVERYONE:READ_DATA::ALLOW
>
> The mode is rw-rw-r--. Now we use ACL tools to change the ACL to  
> give the
> owning group fewer permissions than user@domain as you say:
>
> 	OWNER@:READ_DATA/WRITE_DATA::ALLOW
> 	GROUP@:READ_DATA::ALLOW
> 	user@domain:READ_DATA/WRITE_DATA::ALLOW
> 	EVERYONE:READ_DATA::ALLOW

> The mode must still be rw-rw-r-- because otherwise, user@domain  
> wouldn't have
> WRITE_DATA access. Now a nasty, evil POSIX application that doesn't  
> know
> anything about ACLs comes along and does a chmod(file, 0600), chmod 
> (file,
> 0664). What should be the appropriate result? If changing the group  
> file mode
> permission bits writes through to the GROUP@ entry as you say, then  
> we would
> end up with the following *effective* permissions:
>
> 	OWNER@:READ_DATA/WRITE_DATA::ALLOW
> 	GROUP@:READ_DATA/WRITE_DATA::ALLOW
> 	user@domain:READ_DATA/WRITE_DATA::ALLOW
> 	EVERYONE:READ_DATA::ALLOW

That's not how Solaris works either.  Sorry, I should have explained  
it better.  In Solaris using POSIX-draft ACLs, chmod() changes both  
the group permissions and the mask, simultaneously.  I now understand  
why you were hesitant to have chmod affect the group permissions, but  
having it affect both mask and group solves both problems.

I realize that I'm talking about POSIX-draft ACLs, but the same  
design principles work for NFSv4 ACLs.  chmod() affects the GROUP@  
permissions directly, and also affects the mask, no matter how the  
mask is implemented.

- Sam

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