PROPOSAL: extend UNIX_INFO2 to mark existence of ACLs

[James Peach]

On Jan 22, 2008, at 1:46 PM, Shirish Pargaonkar wrote:

> On Jan 22, 2008 3:32 PM, James Peach <jpeach at apple.com> wrote:
>>
>> On Jan 22, 2008, at 1:23 PM, Steve French wrote:
>>
>>> James Peach wrote:
>>>
>>>> Hi all,
>>>>
>>>> Unix SMB client could often avoid a few round-trips to the server
>>>> if  they could tell whether a file had an ACL at the point where
>>>> they  query its metadata (presumably using the UNIX_INFO2 info
>>>> level).
>>>>
>>>> Since the permissions field is 64bits, how about stealing the high
>>>> bit  of this field to indicate whether the file might have an ACL?
>>>>
>>>> We'd probably need a mechanism for clients to figure out whether
>>>> the  bit was meaningful or not ....
>>>>
>>>>
>>> Do you mean POSIX ACL or NT ACL?
>>> For the case of an NT ACL, how would you distinguish between the
>>> case in which the file has an emulated ACL and a "real" ACL?  If you
>>> query the NT ACL eg. with smbcacls, Samba will report one, even on
>>> files which do not have an ACL.
>>>
>>
>> You might be able to tell that I haven't thought this through very
>> thoroughly yet :)
>>
>> But I think that I agree with Simo that the server should only set  
>> the
>> bit for a "real" ACL, ie. it should not set the bit for files whose
>> only ACL is fabricated from the POSIX permissions bits.
>>
>
> Could someone please explain what are   few round-trips   to the  
> server

to get the security descriptor (or UNIX ACL), you need to do
	open
	trans2
	close

>
> and what is an emulated ACL?

when server creates an NT ACL that is not stored on disk, but is  
created by examining the POSIX permissions, ie. it generally would  
only be able to represent ACEs for the owner, the group and the  
Everybody group (which approximates other)