[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