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
|