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

James Peach jpeach at apple.com
Fri Jan 25 18:46:47 GMT 2008


On Jan 25, 2008, at 10:09 AM, simo wrote:

>
> 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 ?

access(2) is intrinsically racy, so we have to accept that it will  
never be 100%.

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

It's not possible, but it can be made good enough for the most common  
cases. I'm not claiming that this extension makes a perfectly accurate  
implementation 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 ?

The client can determine its server-side token with SMB_WHOAMI
	<http://wiki.samba.org/index.php/UNIX_Extensions#SMB_WHOAMI>

> If I have a force user/force group or read only setting your access
> check will probably return the wrong result.

In this case, the server could reasonably leave the  
UNIX_NO_EXTENDED_PERMISSIONS bit clear.

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

If there is a SELinux label, the server MUST NOT set the  
UNIX_NO_EXTENDED_PERMISSIONS.

If the server can tell that SELinux is enabled but can't tell whether  
a particular file has a label, then it MUST NOT set the  
UNIX_NO_EXTENDED_PERMISSIONS bit.

> 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 ?

In the long run, we ought to have an access call as well. That's just  
not something I have a detailed proposal for yet.





More information about the samba-technical mailing list