[Gluster-devel] Future of access-control translator ?
skoduri at redhat.com
Thu Jun 11 05:53:03 UTC 2015
On 06/11/2015 04:29 AM, Niels de Vos wrote:
> On Wed, Jun 10, 2015 at 11:42:27PM +0530, Jiffin Tony Thottan wrote:
>> In the current implementation of access-control translator, it takes care
>> of the following :
>> a.) conversion of acl xattr <-> gluster supported posix-acl format
>> (at the backend acl is stored as xattr know as system.posix_acl* for linux)
>> b.) Cache that posix-acl in its context.
>> c.) And enforce permissions based on the cached entries.
> Note that the "gluster supported posix-acl format" does not use the
> standard libacl library or equivalent libc (FreeBSD) functions. It is a
> Gluster internal structure that only the posix-acl xlator uses.
>> This translator is loaded in the server side by default and in the client
>> side if acl option is mentioned.
> "client side" is Gluster/FUSE only in this case. Gluster/NFS or libgfapi
> do not have the posix-acl xlator loaded. Also, the choice to load the
> xlator on the client (in addition to the server) is not clear to me.
> - https://github.com/gluster/glusterfs/commit/57b3b7e (point to 2815)
> - https://bugzilla.redhat.com/show_bug.cgi?id=GLUSTER-2815
>> A new portable acl conversion was introduced in posix by  to fix
>> limitations in (a). Refer mail thread 
>> for further details. Enforcement can be handled by posix translator(In that
>> case, caching will be redundant,
>> because same permission are checked twice).
> All modern filesystems support ACLs by default, so I would really prefer
> to use the enforcing and management of ACLs that the kernel (Linux and
> FreeBSD) provide in the VFS. There is only one OS that we as community
> support and that does not seem to have ACLs, and that is NetBSD. I do
> not see the need to support ACLs on NetBSD if NetBSD clients would not
> be able to use them either. Users deploying NetBSD Gluster servers and
> accessing the volume from clients with ACL support will get ENOTSUP
> errors, just like they would as if the local filesystem does not have
>> Therefore should we remove access-control translator entirely from vol graph
>> Retain the translator for (b) and (c) by modifying them based on standard
>> acl format.
> Removing the posix-acl (and its symlinks like "access-control") has my
> support. I understand that removing the xlator uncovered some other
> issues that would need to be addressed first. Once those have been
> resolved, we should be in a good position to remove it.
+1. Atleast the protocols (using gfapi) will process ACLs and do
permission checking in their layer itself. Even if not (like in case of
gNFS or multi-protocol), as you have mentioned the back-end file-system
should rightly enforce the ACL checks.
The only gain I see of having this xlator is to cache and avoid system
calls. But then as proposed, we need to replace usage of "gluster
supported posix-acl format" with the standard APIs provided by libacl*
> (the brick runs as 'root' user, but setfsuid(), setfsgid() and
> setgroups() will change the personality of the process when needed)
>> Please provide your thoughts on the same.
>>  : http://review.gluster.org/#/c/9627/
>>  : http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/9036
> In the future, we are hoping that richacl provides a more portable way.
> The librichacl library provides all the functions that we need,
> including conversion between binary/portable-text and permission
> checking. Rajesh is looking into richacls for Gluster already:
> More comments welcome! Thanks,
> Gluster-devel mailing list
> Gluster-devel at gluster.org
More information about the Gluster-devel