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

[simo]

On Fri, 2008-01-25 at 09:18 -0800, 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).

Uhmm how accurate do you want your client implementation of access(2) to
be ?

I question the possibility of claiming any accurate implementation in
the client is possible.

Take for example a samba server,
even if you have access from the client to both permissions and ACLs how
do you know exactly which ids will the server really evaluate ?
If I have a force user/force group or read only setting your access
check will probably return the wrong result.
Now suppose you don't use these features then again, on Linux at least,
SELinux may prevent the smbd daemon for opening files/directories
depending on their label even if the ACL would actually permit access in
theory.
And we are not considering filesystems that use alternative ACL
implementations.

Wouldn't it make sense to use an "access" call implemented by CIFS
server instead ?

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <ssorce at redhat.com>