[Gluster-devel] Portable filesystem ACLs?

[J. Bruce Fields]

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.
> >
> >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.
> 
> 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.

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.

--b.