[Samba] ACL misbehavior moving from POSIX ACL -> acl_xattr

[Jeremy Allison]

On Wed, Sep 16, 2009 at 11:01:21PM +0100, Miguel Medalha wrote:
>
>>> All files/dirs are 666 or 777.  According to my reading, since there 
>>> are no POSIX extended ACLs, if the VFS layer "passes" an access, then 
>>> it only should be compared against the standard UGO permissions.
>>>     
>>
>> That's correct - but the problem isn't access, it's when the
>> incoming ACL is "set" onto the underlying filesystem. Most
>> ACLs can't be mapped onto ugw permissions.
>>
>> As I said, you need a vfs_acl_null module that will drop
>> any set call, and will return Everyone:Full control on
>> read.
>>   
>
> I am ignorant enough on these low-level matters. I "almost" understand  
> your statement. But... consider the following:
>
> - At the filesystem level ALL the permissions are 666 or 777
> - The above are ONLY seen by the VFS layer, not by the client side
> - The VFS module writes the real ACLs as extended attributes only (or  
> some other method), always setting  them as 666/777 at the filesystem 
> level
> - Clients only see the ACLs provided to them *by the VFS layer* and  
> never directly from the filesystem
>
> Wouldn't this provide any desired type of ACLs? What am I missing here?

Remember, the NTACL vfs module calls down to a lower layer
module to set the mapped acl onto the underlying filesystem.

Without a null ACL module you'll get the following problem:

If you don't have posix acls on the filesystem how do you
map an incoming ACL containing two or more users or groups ?

Can't be done without an underlying ACL implementation.
The mapping code will fail and RETURN AN ERROR. Then
the underlying ACL set will fail, so the entire operation
will fail.

That is what you are missing.

Jeremy.