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

[Niels de Vos]

On Thu, Jun 11, 2015 at 11:23:03AM +0530, Soumya Koduri wrote:
> 
> 
> 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.

The systemcalls are only needed for reading the ACL or manipulating it.
This is a normal extended attribute and md-cache (client- and now
server-side too?) does the caching already too.

The only advantage that the posix-acl xlator offers, is the 'deny' case.
Instead of going to the VFS and get -EPERM, the xlator handles it. My
assumption is that most users care more about the 'allow' cases, and can
accept slower permission denied failures.

Niels

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