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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 20 Oct 2011 13:49:33 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Christoph Hellwig <hch@...radead.org>, agruen@...nel.org,
	akpm@...ux-foundation.org, viro@...iv.linux.org.uk,
	dhowells@...hat.com, linux-fsdevel@...r.kernel.org,
	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	ebiederm@...ssion.com
Subject: Re: [PATCH -V7 21/26] richacl: xattr mapping functions

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@...radead.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/