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