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 _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
