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: <20111021004529.GA12745@fieldses.org>
Date:	Thu, 20 Oct 2011 20:45:29 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Andreas Gruenbacher <agruen@...nel.org>
Cc:	Christoph Hellwig <hch@...radead.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	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 Fri, Oct 21, 2011 at 01:46:29AM +0200, Andreas Gruenbacher wrote:
> On Thu, 2011-10-20 at 06:25 -0400, J. Bruce Fields wrote:
> > 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.
> 
> That makes sense to me.
> 
> There seems to be a WELL_KNOWN_SID_TYPE enumeration which maps those
> kinds of special identifiers to small integers in Windows; maybe it
> makes sense to use the same numbers for OWNER@, GROUP@, and EVERYONE@.
> 
> > 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?
> 
> The acl itself has a version field, so new formats could be introduced
> in the future with a new version.

OK, sounds good.  So let's just assume uid's, and wait to deal with
anything more complicated until we know what's going to happen.  Aneesh,
does that sound good?

And then I think the patches are ready....

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