Messages in this thread | | | Date | Tue, 11 Dec 2001 12:22:58 +1100 | From | Timothy Shimmin <> | Subject | Re: [PATCH] Revised extended attributes interface |
| |
On Mon, Dec 10, 2001 at 11:52:09AM +0000, Stephen C. Tweedie wrote: > On Sat, Dec 08, 2001 at 03:58:41PM +1100, Nathan Scott wrote: > > On Fri, Dec 07, 2001 at 08:20:36PM +0000, Stephen C. Tweedie wrote: > > > > > This is looking OK as far as EAs go. However, there is still no > > > mention of ACLs specifically, except an oblique reference to > > > "system.posix_acl_access". > > > > Yup - there's little mention of ACLs because they are only an > > optional, higher-level consumer of the API, & so didn't seem > > appropriate to document here. > > Unfortunately, if there are many filesystems wanting to use posix > ACLs, then standardising the API is still desirable. True.
> > > We have implemented POSIX ACLs above this interface - there > > is source to new versions of Andreas' user tools here: > > http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/acl2 > > These have been tested with XFS and seem to work fine, so we > > are ready to transition over from our old implementation to > > this new one. > > But the ACL encoding is still hobbled: there's no namespace for > credentials other than uid/gid. This has been brought up before, but > it's worth going over some of the things we'd like to be able to do > with extended credentials again: > [credential examples deleted]
> > Authentication is about *much* more than just local uid/gids, but the > current EA/ACL specs are creating an implicit standard for ACLs > without addressing any of these concerns. > > > The existence of a POSIX ACL implementation using attributes > > system.posix_acl_access and system.posix_acl_default doesn't > > preclude other types of ACLs from being implemented (obviously > > using different attributes) as well of course, if someone had > > an itch to scratch. > > I am not talking about other types of ACLs! I am talking about > *POSIX* ACLs, but using a credentials namespace which is more than > just uid/gid. Only the credentials change: the rest of the POSIX > semantics still apply. The CITI NFSv4 implementation is already doing > POSIX ACLs and GSSAPI krb5 authentication on top of the bestbits API, > so we already have at least one application ready and waiting to use > such an extension. >
So you are particularly interested in more general "qualifiers" (in posix acl entry speak:). Some people are also interested in more general "permissions" for ACEs.
Could this not be catered for independent of the proposed EA interface for getting/setting/removing EAs ? One could come up with more general data structures and functions for ACLs/ACEs than what we currently propose, and yet still use the same EA interface.
--Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |