[Gluster-devel] Future of access-control translator ?

[Soumya Koduri]

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:
>> Hi,
>>
>> 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 [1] to fix
>> limitations in (a). Refer mail thread [2]
>> 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
> ACLs.
>
>> Therefore should we remove access-control translator entirely from vol graph
>> or
>> 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* 
library.

Thanks,
Soumya

>     (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.
>>
>> [1] : http://review.gluster.org/#/c/9627/
>> [2] : 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:
>
>    http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/11054
>
> More comments welcome! Thanks,
> Niels
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>