PROPOSAL: extend UNIX_INFO2 to mark existence of ACLs

[James Peach]

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:
>>> On Jan 22, 2008, at 3:46 PM, Christopher R. Hertel wrote:
>>>
>>>> Jeremy Allison wrote:
>>>>> On Tue, Jan 22, 2008 at 05:16:14PM -0600, Steve French wrote:
>>>>>> There are systems which support Unix Extensions but do not  
>>>>>> support
>>>>>> POSIX
>>>>>> ACLs.
>>>>
>>>> Yep.  I'm working with one such currently.
>>>
>>> I intended that this bit would be set by any server that  
>>> understood the
>>> UNIX_INFO2 info level and had a concept of (on-disk) ACLs the went
>>> further than a one-to-one mapping of the POSIX permissions bits.
>>
>> The SNFS file system does not support POSIX ACLs but does  
>> understand the
>> POSIX permission bits.  The question of whether or not to support  
>> the Unix
>> Extensions in general has been raised.

If the server does not support POSIX ACLs it should not claim the  
CIFS_UNIX_POSIX_ACLS_CAP capability. For a file that has an NT ACL the  
server should set the "extended permissions" bit.

>>> 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).

	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?



>
>
>
>
>> :
>>>> The proposal is to overload the Permissions field in the structure
>>>> returned by the UNIX_INFO2 call.
>>>
>>> No, it's to define an extra bit in this field. The extra bit means
>>> "there are security attributes that aren't represented here".
>>>
>>> #define UNIX_EXTENDED_SECURITY (1<<63) /* choose a less generic  
>>> name! */

UNIX_EXTENDED_PERMISSIONS

>>>
>>>
>>> If a client sees this bit, it can query the security descriptor or  
>>> fetch
>>> the POSIX ACL, whichever it prefers. I expect that most clients that
>>> support the UNIX extensions would simply fetch the ACL.
>>
>> Whether it's overloading or not depends on the original intent of  
>> the use of
>> that field, but I'm splitting hairs.  (I'm good at that.  :)
> It is ok to "overload" them in this case, they are vaguely permission
> related.


To overload means to take an existing name and make it mean something  
else in a different context. Defining a meaning for something that was  
previously meaningless is not overloading :)

--
James Peach | jpeach at samba.org