Re: [PATCH -V7 21/26] richacl: xattr mapping functions

[Andreas Dilger]

On 2011-10-20, at 11:49 AM, J. Bruce Fields wrote:
> On Thu, Oct 20, 2011 at 04:32:04PM +0530, Aneesh Kumar K.V wrote:
>> On Thu, 20 Oct 2011 05:19:46 -0400, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
>>> Storing strings is an extremly stupid idea.  The only thing that would
>>> make sense would be storing a windows-style 128-bit GUID.
>> 
>> How about updating the richacl_xattr as below 
>> 
>> struct richace_xattr {
>> 	__le16		e_type;
>> 	__le16		e_flags;
>> 	__le32		e_mask;
>> 	__le32		e_size;
>> 	u8		e_id[0];
>> };
>> 
>> now e_flags can contain ACE4_SPECIAL_WHO to indicate value in e_id
>> indicate special who values (which could be 1 byte value indicating
>> OWNER@, GROUP@ or EVERYONE@), ACE4_UNIXID_WHO, to indicate value
>> in e_id is the little endian value of unix id. ACE_WINSID_WHO to
>> indicate e_id is the 128 bit array containing SID value. ?
> 
> That's effectively still a string.
> 
> Would it be so bad to have to introduce another xattr type if we needed
> a new id type?  You'll have to modify the filesystem and the userspace
> tools and everything anyway, won't you?
> 
> But if we decide we don't need strings, then at a minimum let's make
> these some fixed small size.
> 
> You could do something like:
> 
> 	struct richace_xattr {
> 		__le16		e_type;
> 		__le16		e_flags;
> 		__le32		e_mask;
> 		__le32		e_id[4];
> 	}
> 
> and just use e_id[0] for now.  That would still leave room for a 128-bit
> id, or for a 32-bit uid + some-size namespace-id.

Just as an FYI, from back when we were trying to port Lustre to Solaris,
Solaris itself uses a 64-bit "FUID" (32-bit UID + 32-bit namespace) to
handle this.

It has a table for arbitrary mapping of 128-bit Windows domains to a
32-bit FUID namespace (don't know much detail here, sorry), and it is
(reasonably) expected that a single system will not be in more than
2^32 namespaces at once.  This keeps the datatypes sane (u64 or 2x u32)
and doesn't put much complexity into the filesystem/kernel.  For most
uses, the high 32-bit value is 0 (local Unix domain).

Cheers, Andreas





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/