[PROPOSAL] extend UNIX_INFO2 to flag extended access controls (take 2)

[James Peach]

On Jan 25, 2008, at 9:51 AM, Steve French wrote:

> James Peach wrote:
>
>> Hi all,
>>
>> This is a modified version of my earlier proposal,
>>    <http://marc.info/?l=samba-technical&m=120103599815292&w=2>
>>
>> I think that this version clarifies my intent and solves the  
>> backwards  compatibility /versioning problem.
>>
>> 1. The Problem
>>
>> The fundamental problem is that a SMB client that uses UNIX_INFO2   
>> isn't able to use the Permissions field to evaluate access(2) if  
>> the  server implements a permissions model that goes beyond the  
>> basic Unix  permissions bits.
>>
>> However, even when the server implements an extended permissions   
>> model, most files residing on the server do not have extended   
>> permission applied to them.
>>
>> If the Unix permissions are the only access control on the file,  
>> then  the client can accurately handle access(2) calls without  
>> making  further round trips to the server (as long as it is  
>> prepared to live  with the race condition).
>>
>> 2. The Proposal
>> #define UNIX_NO_EXTENDED_PERMISSIONS (1<<63)
>> The server MAY set the UNIX_NO_EXTENDED_PERMISSIONS bit in the   
>> UNIX_INFO2 Permissions field if this field completely describes  
>> the  permissions of the file.
>> That is, if the server sets this bit, it is indicating to the  
>> client  that the file has no access control other than the Unix  
>> permissions  bits described in the SNIA QUERY_FILE_UNIX_BASIC  
>> documentation.
>> 3. Compatibility
>> Existing servers that support the Unix extensions leave the   
>> UNIX_NO_EXTENDED_PERMISSIONS clear, indicating that there MAY be  
>> an  extended permissions model in use. In this case, clients SHOULD  
>> uses  their existing strategies for presenting permissions to the  
>> user and  for evaluating access(2).
>>
>>
> I don't mind this (evaluating the permission call properly would be  
> helpful), but I am most concerned with how expensive it is to do  
> this on the server.  If it is too slow, it is cheaper to have the  
> client query.

I guess that only servers that can figure this out cheaply would ever  
set the UNIX_NO_EXTENDED_PERMISSIONS bit. If its too expensive to  
figure out, they just stick with todays status quo.

Note that if the UNIX_NO_EXTENDED_PERMISSIONS is clean it doesn't mean  
that there *is* definitely extended permissions, only that there might  
be. Just like today.