Hi,
On Thu, Nov 02, 2000 at 12:21:10PM +0100, Andreas Gruenbacher wrote:
> On Tue, 31 Oct 2000, Stephen C. Tweedie wrote:
> >
> > The main motivation for having that was simply to deal with ACLs as
> > sets of named ACEs, in just the same way that a file can contain a set
> > of named EAs. Being able to define the namespace separately for each
> > ACE in the ACL was an important property of the API I proposed, since
> > it would allow you to mix both local uids and remote credentials in an
> > ACL.
>
> I have now checked Windows NT and NTFSv4 ACLs. None of NT, NTFS or Posix
> ACLs are modified entry by entry; they are all replaced in their entirety
> (from the point of view of the kernel). I think passing individual ACEs
> separately to the kernel makes no sense.
Then you missed the point --- the idea wasn't to allow ACLs to be
modified one entry at a time, but rather to allow the namespace to be
specified individually on each ACE.
Think about the NFSv4 case, for example. The kernel already _has_ to
do mapping between local uid/gids and remote utf/8 credentials,
because operations such as chown and stat are specified in terms of
uid (to the application) and utf/8 (to the server). You want to be
able to take advantage of that mapping by specifying ACEs in terms of
local uids if you want to control local access, but you need to be
able to specify other ACEs in terms of utf/8 for remote accessors.
And even for POSIX ACLs, you want to be able to support filesystems
which offer non-standard credentials --- I might well want to add an
extension to ext2 POSIX ACLs to support NT SID identifiers while
retaining POSIX semantics, so that on a samba machine we get
consistent enforcement of ACLs for local and remote users.
> I see that we need to support other ACE namespaces in addition to uid/gid.
> However, that still doesn't mean the namespace must be defined per ACE.
>
> The extended attribute name would imply the namespace, like this:
>
> EA name ACL namespace Semantics
> ------- ------------- ---------
> system.acl uid/gid Posix ACLs
> system.nfs_acl name@domain NFSv4 ACLs
That doesn't work for mixing namespaces within one set of semantics,
as in the two examples above.
> This would allow the userspace utility to work with ACLs in different
> namespaces, but would greatly simplify the kernel's task of recognizing
> correct ACLs and namespace conversion.
But check the NFS case again: the kernel already *must* do the
mapping, so you're just forcing that same code to be implemented
twice, once in user space and once in the kernel.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
