On Tue, Dec 16, 2014 at 1:48 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > On Sun, Dec 14, 2014 at 07:24:52PM +0530, Soumya Koduri wrote: >> >> >> On 12/12/2014 11:06 PM, Niels de Vos wrote: >> >Hi, >> > >> >I started to look into getting some form of support for ACLs in gfapi. >> > >> >After a short discussion with Shyam, some investigation showed that our >> >current implementation of ACLs is not very portable. There definitely >> >seem to be issues with ACLs when a FUSE mount is used on FreeBSD, and >> >the bricks are on a Linux system. >> > >> >Our current implementations of (POSIX) ACLs is very much focussed on the >> >Linux behaviour. For example, there is the assumption that ACLs are >> >stored in the system.posix_acl_access extended attribute. FreeBSD uses a >> >system.posix1e.acl_access xattr. Other platforms likely use an other >> >variation. Also the (binary) encoding of the contens most definitely >> >differs per platform. >> > >> >In order to provide a good experience with ACLs on different platforms, >> >we could introduce a solution like this: >> > >> > setfacl ... >> > | >> > v >> > glusterfs client (like fuse) >> > | >> > v >> > some API, possibly transparent in the posix-acl xlator >> > | converts the client-platform specific ACL into >> > | a Gluster ACL format >> > v >> > Outgoing RPC procedure, a new SET_ACL, or as SETXATTR(gluster.acl) >> > | >> > v >> > [network] >> > | >> > v >> > Incoming RPC procedure on the brick (can be different platform) >> > | >> > v >> > Conversion from Gluster/ACL format to platform specific, possibly in >> > | the storage/posix xlator >> > v >> > setfacl() syscall/library call to store the ACL on the filesystem >> > >> > >> >Reading the ACL would be the same, just in reverse. I like this idea. We have faced similar issues with ACL when integrating Samba with GlusterFS. Samba internally uses libacl to set/get acls. However, when using our vfs plugin to make Samba work with GlusterFS volume it is not possible to make calls to libacl. We are currently packaging ACLs into correct setxattr calls in our vfs plugin and passing it over to gfapi. However, libacl does much more than that. It allows users to call set_acl with a liberal format for ACLs and takes care of packaging them in right way etc. With your approach where we have two xlators, one on the client side and other on the server side, we can take care of this. Just fail the call on the client side if it is not as per the standard on that particular client. On the server side, we can do validations which are dependent on the already existing ACLs, ownership etc and set it on disk. >> > >> >It would be most welcome to have some kind of API that can get exposed >> >in gfapi, so that NFS-Ganesha and other gfapi applications can get/set >> >ACLs in a standardized way. One option is to use the (possibly platform >> >dependent) structures defined by libacl or librichacl. >> From a quick look at the code, 'libacl' seems to be supporting only >> 'system.posix_acl_access' xattr. >> >> IMO it may be good to have a standard 'acl_obj' structure in RichACL >> format itself, which Multi-protocol team (CCed) has been looking at >> & which you have been suggesting. This structure can be exposed to >> the applications(NFS-Ganesha/SAMBA) to fill-in ACLs data and >> probably call 'glfs_set_acl(..)' which in turn converts these >> 'acl_obj's to platform dependent acl xattrs and make a >> syncop_setxattr call. >> In the first phase it would be good to support only as much as libacl supports. >> And in future, if we get RichACL support, we could just >> extend/modify this routine to send in those ACLs as is to the >> back-end. Yes, we should choose a structure which would support extension to other ACL formats. > > Translating automatically between FreeBSD and Linux ACLs makes sense, I > think, as long as the only differences are trivial encoding and naming > issues. > > Translating between completely different ACL models could quickly get > more complicated than its worth. Agree here too, hence the request to go with libacl mode at first and then extend to other formats. We cannot choose to support all modes without having algorithm in place to convert from one to other. > > --b. > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxxx > http://supercolony.gluster.org/mailman/listinfo/gluster-devel -- Raghavendra Talur _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
