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]

Message-ID: <m1lircxxo0.fsf@fess.ebiederm.org>
Date:	Sat, 19 Nov 2011 01:35:11 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	"J. Bruce Fields" <bfields@...ldses.org>,
	"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,
	"Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [PATCH -V7 21/26] richacl: xattr mapping functions

Andreas Dilger <adilger@...ger.ca> writes:

> 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).

Interesting.  For now it looks to me like a fixed partitions of a uid
into a namespace identifier and a normal uid is a brittle path to walk.

I am looking at using something slightly more dynamic.  Here for your
user namespace you get this range of uids.  That nests better and
allows for more flexibility in the future.

I think I can mostly keep filesystems where they don't care.  With just
a few places changes where we take the filesystem uid and map it into
what we store in the vfs cache.  And when we read the uid value out
of the vfs cache and map it into the id value that the filesystem
needs.

Eric
--
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/