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

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

[Dave Kleikamp]

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

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.  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).

-- 
David Kleikamp
IBM Linux Technology Center

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

[Andreas Gruenbacher]

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.

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

[Michael Tokarev]

Dave Kleikamp wrote:
[]
> On Tuesday 08 October 2002 13:02, Andreas Gruenbacher wrote:
[]
>>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.
[]
>>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 

Just a random thought (sorry if it was discussed before) - I don't
see why every filesystem with it's own unique layout etc should store
ACLs as xattrs - there may be different implementation especially for
ACLs but no xattrs at all (at the beginning of the "ACL era", almost
everyone agreed that ACL/xattrs subsystem should be more-or-less
universal, allowing many different layouts/concepts (think NTFS
ACLs vs POSIX ACLs) to be used).  Well, conversion routines may
exists (if at all possible), but in some cases this will be an
overkill.

/mjt

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

[Spencer Shepler]

On Tue, Michael Tokarev wrote:
> Dave Kleikamp wrote:
> []
> >On Tuesday 08 October 2002 13:02, Andreas Gruenbacher wrote:
> []
> >>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.
> []
> >>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 
> 
> Just a random thought (sorry if it was discussed before) - I don't
> see why every filesystem with it's own unique layout etc should store
> ACLs as xattrs - there may be different implementation especially for
> ACLs but no xattrs at all (at the beginning of the "ACL era", almost
> everyone agreed that ACL/xattrs subsystem should be more-or-less
> universal, allowing many different layouts/concepts (think NTFS
> ACLs vs POSIX ACLs) to be used).  Well, conversion routines may
> exists (if at all possible), but in some cases this will be an
> overkill.

This would certainly be true of NFSv4 where ACLs are part of the
semantically defined attributes and are not part of the xattr space.
Using [gs]et_posic_acl() would make the translation job
straightforward for the NFS client/server.

-- 
Spencer

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

[Dave Kleikamp]

On Tuesday 08 October 2002 14:33, Andreas Gruenbacher wrote:
> On Tuesday 08 October 2002 20:57, Dave Kleikamp wrote:
> > 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.

I want to do this once.  If ACL's are set by set_posix_acl, let it 
verify the thing.  Let set_xattr worry about the storage.  If you want 
set_xattr to do everything, get rid of set_posix_acl.

> A
> separate syscall would spare the name dispatching and endian
> conversion code.

It would just push it down into the fs layer, where it would still be 
name-dispatched and endian-converted.

> In the applications I have seen so far the xattr
> syscalls aren't called frequently enough for that to become a
> problem.

My concern is not how often the code runs, but in where we implement it.  
I think if we are going to have a [gs]et_posix_acl interface, let's put 
all of the acl-dependent code here.  Let [gs]et_xattr worry about the 
storage.

> > 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.
Not really.  I'm just thinking if you have a separate interface, there's 
no requirement that the two be tied together.

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

That's why I mentioned that i_acl and i_default_acl should be moved to 
the generic inode.  This way the xattr code would only be called if we 
have to go to disk anyway.

> 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 would be a special case, not a full-fledged name dispatcher.

> > 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.)

If all of the fs's are expected to treat ACL's the same way, why 
shouldn't there be common code to handle them?  Anyway, I'm all for 
getting rid of the posix_acl operations.  I just don't like the idea of 
implementing the same function in two different inode operations.

>
> --Andreas.

-- 
David Kleikamp
IBM Linux Technology Center

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

[Dave Kleikamp]

On Tuesday 08 October 2002 15:04, Spencer Shepler wrote:
> On Tue, Michael Tokarev wrote:
> > Just a random thought (sorry if it was discussed before) - I don't
> > see why every filesystem with it's own unique layout etc should
> > store ACLs as xattrs - there may be different implementation
> > especially for ACLs but no xattrs at all (at the beginning of the
> > "ACL era", almost everyone agreed that ACL/xattrs subsystem should
> > be more-or-less universal, allowing many different layouts/concepts
> > (think NTFS ACLs vs POSIX ACLs) to be used).  Well, conversion
> > routines may exists (if at all possible), but in some cases this
> > will be an overkill.
>
> This would certainly be true of NFSv4 where ACLs are part of the
> semantically defined attributes and are not part of the xattr space.
> Using [gs]et_posic_acl() would make the translation job
> straightforward for the NFS client/server.

The xattr space is broken down into namespaces that the fs's are free to 
handle any way they wish, so even though the ACL's may come in as an 
xattr, the fs can store it any way it chooses.

This is where I argue that IF we have a separate ACL interface, there's 
no need to require that the xattr interface be used to store the ACL, 
but since most filesystems will use xattrs, we should have a generic 
function that stores/retrieves the ACL in the form of an xattr (and 
caches the ACL for fast access).

If we decide NOT to have a separate ACL interface, the filesystem would 
then deal with the ACL's based on the xattr namespace.  It has the 
freedom to actually store the ACL as an xattr, or in some other 
fashion.  In this case, I still argue for a generic get_posix_acl (not 
a file operation) that calls the fs's get_xattr.  I don't see a need 
for every fs to implement this function.
-- 
David Kleikamp
IBM Linux Technology Center