Re: [PATCH] Revised extended attributes interface

["Stephen C. Tweedie" <sct@redhat.com>]

Hi,

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.

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

* NFSv4.  

NFSv4 credentials are of the form "user@realm", and an NFSv4 server
needs to be able to apply ACLs using such credentials so that it can
securely serve users in foreign realms.

* Kerberos single-signon.

I want to be able to get a kerberos login ticket on the desktop in
front of me and access files in my entire organisation securely.  I
want to be able to login to remote systems in different departments
and still have ACLs work.  So "foo@SALES.CO.COM" might login to a
machine in the "DEVEL.CO.COM", and would only get a "guest" uid, but
the ACL system would allow access based on the full "foo@SALES.CO.COM"
credentials.

* Samba.

Is there any reason not to allow an NT SID to be used as the
credential for an ACL?

* Sub-IDs.

There was a beautiful paper presented at a recent Usenix in which the
concept of user-manageable sub-ids was presented.  I am on a secure
intranet, but I'm constantly accessing untrusted data.  Every time
Mozilla accesses a web site I am potentially vulnerable to web
rendering bugs which could allow a site to take over my machine.
Plugins such as flash just make the matter worse.  Even in the home
environment we'd like to make it easy to allow multiuser games to be
run without compromising the whole local system.

The sub-id concept proposes allowing users to create process groups
with restricted rights to the system.  I would _really_ like to give
Mozilla write access to ~/tmp and ~/.mozilla, but not to the rest of
my homedir.  Can't I use a "sct/mozilla" credential for my ACLs?


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.

Cheers,
 Stephen