Re: [PATCH] Revised extended attributes interface

[Anton Altaparmakov]

At 18:23 11/12/01, Hans Reiser wrote:
>Stephen C. Tweedie wrote:
>The proposal defines two "families" of attribute entities: attribute
>>families and name families.
>>
>>An attribute family might be ATR_USER or ATR_SYSTEM to specify that we
>>are dealing with arbitrary user or system named extended attributes,
>>or ATR_POSIXACL to specify POSIX-semantics ACLs.  Obviously, this can
>>be extended to other ACL semantics without revving the API --- a new
>>attribute family would be all that is needed.
>>
>>The "name family" is the other part of the equation.  Attributes in
>>the ATR_USER or ATR_SYSTEM families might be named with counted
>>strings, so they would have names in the ANAME_STRING name family.
>>POSIX ACLs, however, have a different namespace: ANAME_UID or
>>ANAME_GID.  The API cleanly deals with the difference between user and
>>group ACLs.  It also makes it easy to add support later on for more
>>complex operations: if we want to add NT SID support to ext2 ACLs so
>>that Samba and local accesses get the same access control, we can pass
>>ANAME_NTSID names to the ATR_POSIXACL attribute family without
>>changing the API.
>If you have given it some thought, which your writing hints you may have, 
>can you say a little about supporting NT SIDS and NT ACLs by Linux, and 
>how that can be hard and easy?
>
>One of my programmers is arguing that NT (as opposed to POSIX) ACL support 
>is harder than I imagine due to SIDS, and.... your view would be interesting.

SIDs are nothing but user ids so you just require the user to pass a 
mapping between SIDs and Linux user&group ids at mount time and that 
problem is solved.

I am told samba already has support for SIDs so it can't be that difficult. (-:

Best regards,

         Anton