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