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 06:25:38 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	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
Subject: Re: [PATCH -V7 21/26] richacl: xattr mapping functions

On Thu, Oct 20, 2011 at 05:19:46AM -0400, Christoph Hellwig wrote:
> On Thu, Oct 20, 2011 at 05:14:34AM -0400, J. Bruce Fields wrote:
> > > > Does it really make sense to use a string here just to pick between the
> > > > three choices OWNER@, GROUP@, and EVERYONE@?  Why not just another small
> > > > integer?  Is the goal to expand this somehow eventually?
> > > 
> 
> > > I guess Andreas wanted the disk layout to be able to store user@...ain
> > > format if needed.
> > 
> > Is that likely?  For that to be useful, tasks would need to be able to
> > run as user@...ain strings.  And we'd probably want owners and groups to
> > also be user@...ain strings.
> > 
> > The container people seem to eventually want to add some kind of
> > namespace identifier everywhere:
> > 
> > 	http://marc.info/?l=linux-kernel&m=131836778427871&w=2
> > 
> > in which case I guess we'd likely end up with (uid, user namespace id)
> > instead of user@...ain?
> 
> 
> Storing strings is an extremly stupid idea.  The only thing that would
> make sense would be storing a windows-style 128-bit GUID.
> 

So if we want to do this without strings:

> > > +struct richace_xattr {
> > > + __le16          e_type;
> > > + __le16          e_flags;
> > > + __le32          e_mask;
> > > + __le32          e_id;
> > > + char            e_who[0];

We could drop that last field and use some predefined values for e_id to
represent owner/group/everyone in the e_type == ACE4_SPECIAL_WHO case.

Then I'm not sure how you'd extend it if you later decided to add
Windows GUID's or whatever.

But maybe it's not realistic to expect to be able to do that without a
new interface and on-disk format: how could old software be expected to
deal with acls that didn't use uid's?

--b.
--
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/