PROPOSAL: extend UNIX_INFO2 to mark existence of ACLs

James Peach jpeach at apple.com
Wed Jan 23 00:14:59 GMT 2008


On Jan 22, 2008, at 3:46 PM, Christopher R. Hertel wrote:

> Jeremy Allison wrote:
>> On Tue, Jan 22, 2008 at 05:16:14PM -0600, Steve French wrote:
>>> There are systems which support Unix Extensions but do not support  
>>> POSIX
>>> ACLs.
>
> Yep.  I'm working with one such currently.

I intended that this bit would be set by any server that understood  
the UNIX_INFO2 info level and had a concept of (on-disk) ACLs the went  
further than a one-to-one mapping of the POSIX permissions bits.

 From a client point of view, the bit is flagging whether there is any  
more security information to fetch that isn't in the UNIX_INFO2  
response. Whether the extra security information is a POSIX ACL or a  
NT security descriptor doesn't mater all that much (ie. the server has  
to unify these somehow anyway).

>> Then they would have a zero in the "POSIX ACL exists" bit :-)
>
> As I understand it, the goal is to return a flag indicating whether  
> or not a
> Posix ACL (or similar Unixy ACL such as an NFSv4 ACL) exists  
> natively in the
> underlying file system on the server side.  This ACL would only be  
> used with
> the Unix extensions, and would provide Unix/Posix semantics.
>
> The proposal is to overload the Permissions field in the structure  
> returned
> by the UNIX_INFO2 call.

No, it's to define an extra bit in this field. The extra bit means  
"there are security attributes that aren't represented here".

#define UNIX_EXTENDED_SECURITY (1<<63) /* choose a less generic name! */

If a client sees this bit, it can query the security descriptor or  
fetch the POSIX ACL, whichever it prefers. I expect that most clients  
that support the UNIX extensions would simply fetch the ACL.

>
>
> Let me know how far off base I am.
>
> Shame there aren't any "reserved" fields in the return block.
>
> Chris -)-----
>
> -- 
> "Implementing CIFS - the Common Internet FileSystem"    ISBN:  
> 013047116X
> Samba Team -- http://www.samba.org/    -)-----     Christopher R.  
> Hertel
> jCIFS Team -- http://jcifs.samba.org/  -)-----  ubiqx development,  
> uninq
> ubiqx Team -- http://www.ubiqx.org/    -)-----          crh at ubiqx.mn.org
> OnLineBook -- http://ubiqx.org/cifs/   -)-----             crh at ubiqx.org



More information about the samba-technical mailing list