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

[Steve French]

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.