Re: [Acl-Devel] Status of ACL patches regarding inclusion in the standard kernel?

[Andreas Gruenbacher <agruen@suse.de>]

On Tuesday 08 October 2002 20:57, Dave Kleikamp wrote:
> I'm copying fsdevel to get a wider circulation.  We're again discussing
> what needs to be resolved in order to merge ACL's into the mainline
> kernel.
>
> On Tuesday 08 October 2002 13:02, Andreas Gruenbacher wrote:
> > One additional issue is the code path from user space to the file
> > system:
> >
> > 	User space:
> > 		machine dependent representation
> > 	System calls & VFS:
> > 		machine independent representation
> > 	File system:
> > 		machine dependent representation
> > 	Physical level:
> > 		machine independent representation
> >
> > Some of the conversions between representations could be avoided with
> > a different system call interface (i.e., separate system calls for
> > ACLs, etc.), but this would confuse the conceptually clean xattr
> > interface.
>
> I could argue that separate interfaces would allow the xattr interface
> to be cleaner.  This of course would depend upon enforcing that the ACL
> xattrs can only be changed via the ACL interface.  This way the xattr
> code wouldn't have to concern itself with changes to the permissions.
> It wouldn't have to parse the ACL value whatsoever.

You want to parse the ACL value to ensure it's a valid one. A separate syscall 
would spare the name dispatching and endian conversion code. In the 
applications I have seen so far the xattr syscalls aren't called frequently 
enough for that to become a problem.

> It would also
> provide a layer where a generic routine could easily be put independent
> of the fs's xattr implementations.

> Finally if an fs decided to store
> the ACL's outside of an extended attribute, it could be done without
> having to go the the xattr operation.

It would essentially have a different name. Is there anything wrong with 
calling an ACL a kind of extended attribute? I don't think there is.

> On the other hand, it may be much easier to get the current xattr
> implentation accepted into the mainline kernels, since it would require
> no new system calls or vfs operations.  And there would be no need for
> users of the existing code to upgrade to new userland tools.
>
> > Another issue are the [gse]et_posix_acl() VFS operations. They are
> > intended to provide fast access to ACLs to in-kernel code. Only
> > get_posix_acl() is used by NFS at the moment; some think that all
> > accesses should be done via the xattr VFS operations.
>
> I think that all ACL access should either go through the xattr calls or
> through [gs]et-posix_acl, but not both.  If we allow the user-space to
> get/set ACL's through [gs]etxattr, than all the code has to be in these
> routines anyway.  A generic [gs]et_posix_acl can be written which calls
> [gs]etxattr, without pushing this down into the file operations.

The point was to avoid the overhead of going through the xattr interface 
inside the kernel, for operations that better should be fast. If on the other 
hand all ACLs would be accessed through the [gs]et_posix_acl() inode 
operations we would need some xattr name dispatcher code in the VFS.

> It could still cache the acl's by moving i_acl and i_default_acl to the
> generic inode (which the fs's xattr code could would also maintain).

I wanted to keep as much of the ACL code down at the filesystem level, so 
currently the VFS only has the MS_POSIX_ACL mount flag, and the two acl inode 
operations. (Once NFSv2 has become obsolete the NFS code eventually won't 
need the get_posix_acl operation anymore, so unless another valid user 
emerges we might even get rid of the posix_acl inode operations entirely.)

--Andreas.