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

[Niels de Vos]

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.

   (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