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

["Noveck, Dave" <[e-mail]>]

Andreas has asked that we consider his proposal when disucssing 
where to go with regard to ACL in v4.1, at the Montreal IETF
meeting.

I'm wondering whether we should be discussing specific mechanisms.
It would help me if we could have a discussion of what the goals
should be for ACL's in v4.1.  This isn't resally clear to me but
it could be due to my lack of attention to the matter.

Is there anybody who's going to be at Montreal who could lead such
a discussion (I'm thinking 10 minutes worth)?  Or are the goals
already clear in which case somebody can explain things to me 
offline and we can avoid wasting other people's time. 

-----Original Message-----
From: Sam Falkner [mailto:[e-mail]] 
Sent: Saturday, July 08, 2006 10:32 AM
To: Sam Falkner
Cc: [e-mail]; Spencer Shepler; Pawlowski, Brian;
[e-mail]; Lisa Week
Subject: Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /
mask,draft-ietf-nfsv4-acls-00 not ready

On Jul 7, 2006, at 9:45 PM, Sam Falkner wrote:

> On Jul 7, 2006, at 5:55 AM, Andreas Gruenbacher wrote:
>>
>> Alternative Proposal
>> ====================
>>
>> Instead of adding DENY entries to the ACL for the purpose of masking,

>> attach three optional attributes to each file: owner_class_mask, 
>> group_class_mask, and other_class_mask. When those attributes are 
>> present, they define which permissions in an ACE are effective.
>>
>> Each ACE is is restricted by one of these mask attributes in each 
>> access
>> check:
>>
>>  - OWNER@ entries and entries for the user@domain that currently owns

>> the file
>>    are restricted by owner_class_mask.
>>
>>  - EVERYONE@ entries are restricted by other_class_mask.
>>
>>  - All other entries are restricted by group_class_mask.
>>
>> The effective permissions are computed as the bitwise and (&) of the 
>> ACE mask and the associated class_mask attribute.
>
> I take it you mean that "the effective access mask bits for ACEs of 
> type ALLOW"?
>
>> When doing a chmod(2) or when applying a create mask, the 
>> owner_class_mask, group_class_mask, and other_class_mask attributes 
>> are modified according to the owner class, group class, and other 
>> class permissions of the mode parameter as follows:
>>
>>  - The POSIX read permission implies the ACE4_READ_DATA, 
>> ACE4_READ_ATTRIBUTES, ACE4_READ_ACL, and ACE4_SYNCHRONIZE bitmask 
>> flags.
>>
>>  - The POSIX write permission implies the ACE4_WRITE_DATA, 
>> ACE4_APPEND_DATA, ACE4_WRITE_ATTRIBUTES, ACE4_DELETE_CHILD, and 
>> ACE4_SYNCHRONIZE bitmask flags.
>
> I'm not sure I agree about ACE4_WRITE_ATTRIBUTES, but that's a minor 
> detail.
>
>>  - The POSIX execute permission implies the ACE4_EXECUTE mask.
>
>> This saves us from bloating ACLs with DENY entries, is more efficient

>> when doing a chmod, and also saves us from destroying permissions in 
>> user provided DENY entries.
>
> Yes, but at the cost of adding new file attributes...  Don't get me 
> wrong, I do see merit in this proposal, but I don't know if it'll be 
> acceptable.
>
>> When an ACL is set, then set all mask attributes to the values 
>> provided in the same SETATTR operation, and set the remaining mask 
>> attributes to the union of all ALLOW ACL entries in the ACL that the 
>> class applies to.
>
> This doesn't take the ordering of the ACL into account; is this your 
> intention?  So
>
> GROUP@:read_data/write_data:DENY
> GROUP@:read_data/write_data:ALLOW
>
> would result in a group_class_mask of read_data|write_data, right?   
> (I'm not saying it's wrong, I'm just making sure I understand.)
>
>> Without any further changes, NFSv4 clients not aware of the three 
>> optional attributes would not be aware of the restrictions imposed by

>> those masks when querying for the ACL. This would create an 
>> interoperability problem, and possible security holes. To solve this 
>> problem, we can extend the GETATTR operation as follows:
>>
>> When a client requests the ACL attribute, check if it also requests 
>> one or more of the three optional owner_class_mask, group_class_mask,

>> or other_class_mask attributes. If it does, then send the requested 
>> attributes as they are. If the client requests only the ACL without 
>> any of the masks, return an ACL with only effective mask flags set, 
>> and with all other flags removed.
>
> I assume you mean in the ALLOW ACEs only, right?

More thoughts on this model and getattr.  Giving different versions of
the ACL depending on how it's requested leads to problems.  To recap, if
NFSv4.0 client asks for the post-chmod ACL, it'll get the inhibited
version of the ACL.  Tools for modifying an ACL invariably do
read/modify/write.  So NFSv4.0 client reads the stripped down ACL,
modifies it, and writes it back.  At this point, information is lost
-- the stripped down ACL is now the only ACL we have.  This leads to
future environments where some classes of clients inadvertently do bad
things, while others behave more correctly.

The ACL model in draft-ietf-nfsv4-minorversion1-03.txt always shows
every client the entire, correct ACL, every time.

- Sam

>
>> Alternate permissions in the ACL can be enabled by either setting an 
>> ACL without providing full mask entries, or by setting the 
>> appropriate
>> bit(s) in
>> the corresponding mask entry or entries.
>
> Yes, I think I understand.
>
>> When comparing POSIX ACLs and the NFSv4 ACL + mask attributes as 
>> proposed here, one obvious difference is that POSIX ACLs have only 
>> one mask entry, while I propose three mask entries here. The reason 
>> for this is that POSIX ACLs can at most grant read, write, and 
>> execute permissions, and so with POSIX ACLs, the File Owner Class 
>> permissions are always identical to the permissions granted to the 
>> owner, and the File Other Class permissions are always identical to 
>> the permissions granted to others. With NFSv4 ACLs, OWNER@ and 
>> EVERYONE@ entries may grant additional permissions that go beyond 
>> what POSIX read, write, and execute can grant, and we need a 
>> mechanism so that those alternate permissions can be turned off by 
>> chmod and during file create without destroying the permissions.
>
> Given that EVERYONE@ is not equivalent to the POSIX "other" class, it 
> could be trimmed down to two.
>
>> I would appreciate if you could take this alternative proposal into 
>> consideration when deciding how to proceed with NFSv4 Minor Version 1

>> at next week's IETF 66 meeting.
>
> This proposal certainly has its merits.  I have doubts about the 
> feasibility of adding two or three new file attributes, and new as- 
> yet-unimplemented semantics, into the minorversion1 draft.  I have 
> doubts about how this would be implemented on a Windows-based server.
>
> The current design specified in draft-ietf-nfsv4- minorversion1-03.txt

> has implementation experience -- it's released in Solaris 10 update 3,

> a shipping product.  It meets strict POSIX requirements for those 
> implementations that choose to conform to POSIX.  I believe it's fully

> implementable on a Windows-based server.
>
> I too hope that this can be discussed at IETF 66.
>
> - Sam
>
>>
>>
>> Thanks and best regards,
>> Andreas
>>
>>> REFERENCES
>>>
>>> [1] Sam Falkner et al.: NFS Version 4 ACLs, draft-ietf-nfsv4- 
>>> acls-00.txt
>>>
>>> [2] POSIX 1003.1e/2c draft 17 (withdrawn), 
>>> http://wt.xpilot.org/publications/posix.1e
>>>
>>> [3] Marius Aamodt Eriksen et al.: Mapping Between NFSv4 and Posix 
>>> Draft ACLs, draft-ietf-nfsv4-acl-mapping-04.txt
>>>
>>> [4] Spencer Shepler (editor): NFSv4 Minor Version 1, 
>>> draft-ietf-nfsv4-minorversion1-03.txt
>>
>> --
>> Andreas Gruenbacher <[e-mail]>
>> Novell / SUSE Labs
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nfsv4


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

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