PROPOSAL: extend UNIX_INFO2 to mark existence of ACLs

[Steve French]

James Peach wrote:

> On 22/01/2008, at 7:05 PM, Steve French wrote:
>
>> On Tue, 2008-01-22 at 20:11 -0600, Christopher R. Hertel wrote:
>>
>>> James Peach wrote:
>>
>>>> From a client point of view, the bit is flagging whether there is  any
>>>> more security information to fetch that isn't in the UNIX_INFO2
>>>> response. Whether the extra security information is a POSIX ACL or  
>>>> a NT
>>>> security descriptor doesn't mater all that much (ie. the server  
>>>> has to
>>>> unify these somehow anyway).
>>>
>>>
>>> Actually not.  Yes, I've already had this discussion and I  
>>> appreciated the
>>> points made, but under SNFS the POSIX and Windows access controls  
>>> are kept
>>> separate.  The task I have been given is to extend the Windows  
>>> semantics to
>>> CIFS clients.
>>
>> I agree with Chris, a POSIX ACL is different from a CIFS ACL and the
>> difference does matter.
>
> Yes the different matters, but I think you're reading more into the  
> proposal than I intend. All I am proposing is that there be a way to  
> indicate that the POSIX permissions aren't the full story.
>
> I'm specifically *not* proposing that there be a set of bits to  
> express every possible combination of permission models supported by  
> the server.
>
>>  It is preferable to fetch the "native" ACL if
>> possible.   Unfortunately a Samba server will return a CIFS ACL  
>> (even if
>> the file system under it does not have such) but it will not  
>> necessarily
>> even be able to return a POSIX ACL (if the Unix CAP for that is off
>> e.g.).
>
> If the NT ACL is a direct representation of the POSIX permission 
> bits,  or the POSIX permission bits are the only arbiters of the 
> server  access check, then the server should not set the "extended  
> permissions" bit. In this case, the POSIX permissions are the full  
> story. There is no supplementary security model.
>
>>  Although I can agree with those who would consider NFSv4 and
>> CIFS ACLs close enough for this purpose, it seems like this bit should
>> either represent the presence of a POSIX ACL (only) and therefore be
>> meaningless if POSIX ACLs were not negotiated or we steal another  
>> bit so
>> we can decide which ACL to query - if we go to the trouble of  extending
>> the protocol it does not seem to do much good to lose performance on  
>> the
>> Query of the ACL by having to query in many cases (remember that in  
>> many
>> cases the server may have files with different types of ACLs or  
>> subtrees
>> under the same share with different native ACL models)
>
>
> There are a number of possible security models on the (UNIX-based)  
> server:
>
>     1. only POSIX permissions are stored
>     In this case the server might generate NT or POSIX ACLs that are  
> equivalent to the POSIX ACLs, but can't deal with anything more  
> complicated
>
>     2. POSIX permissions + unified ACL model
>     In this case the server takes an internal ACL model and maps it 
> to  the POSIX and NT ACL models as best it can (eg. Darwin).
>
>     3. POSIX permissions + POSIX ACLs
>     In this case, the server maps POSIX ACLs to NT ACLs as best it 
> can  (eg. Linux).

Linux is mostly this case, but not completely.
Linux also has a couple of file systems that can retrieve NFSv4 ACLs and 
I expect that
eventually Andreas's patch (or something like it) to store NFSv4 ACLs as 
xattrs in the
other local fs will go in.   Eventually we will also need to 
(optionally) be able to
use on-disk NTFS ACLs when mounted over Linux NTFS.

>     4. POSIX permissions + NT ACLs
>     In this case the server maps NT ACLs to POSIX ACLs as best it can.
>
>     5. POSIX permissions + POSIX ACLs + NT ACLs
>     In this case the server chooses (somehow) which security model to  
> apply. Hybrid client might be SoL.
>
> Note that I've assumed that servers supporting some sort of ACL model  
> will always support NT ACLs. Are there any servers that support POSIX  
> ACLs but not (at least a subset of) NT ACLs?
>
> Now suppose that we had 2 bits - 1 to say whether there was an NT ACL  
> and 1 to say whether there was a POSIX ACL. Now you have a client 
> that  uses some (not necessarily all) of the Unix extensions, and it 
> is  trying to implement access(2). It does the UNIX_INFO2 request and  
> finds that both ACL bits are set. Which ACL should it fetch? What  
> should it do if they are not the same? How would it even know how to  
> compare the 2 ACLs for equality?

We wouldn't compare them - but it saves time if the application (e.g. ls 
or an ACL browser or file manager) is querying a series of files to know 
which one is which (remembering that particular files could have one or 
the other ACL type).   It is worth exploring in more detail how the 
Samba server would tell whether there is a native ACL - and whether the 
query would slow things down enough to cancel the benefits of reducing 
the number of queries over the network the client might do do.  Are we 
already querying xattrs for every inode we do stat on?