[Gluster-devel] Portable filesystem ACLs?

Wed Dec 17 08:49:21 UTC 2014

On Tue, Dec 16, 2014 at 04:16:10PM +0530, RAGHAVENDRA TALUR wrote:
> On Tue, Dec 16, 2014 at 1:48 AM, J. Bruce Fields <bfields at fieldses.org> 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.

Okay, something similar has been implemented in the posix-acl xlator
(client side) too, and we would need an other variation in NFS-Ganesha
as well. A single implementation would benefit us all.

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

Indeed, the idea is to move the ACL setting/getting into Gluster, and
make things more portable.

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

Yes, definitely. This is the plan :)

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

libacl and librichacl are just different. I do not see a need to have a
one format inside Gluster. If we would send a "gluster.posix_acl" over
RPC, we can do the same for a "gluster.rich_acl".

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

Indeed, and in NFS-Ganesha we will need to convert the NFSv4 ACL to
POSIX ACL and use the future Gluster API to use the POSIX ACL. We might
want to store a full NFSv4 ACL (or Rich ACL?) in addition to the POSIX
ACL, but that is a discussion that we need to have on the NFS-Ganesha
side.

Luckily there are some details about converting NFSv4 <-> POSIX ACLs
already (thanks Bruce!):
- http://www.citi.umich.edu/projects/nfsv4/linux/using-acls.html
- http://www.citi.umich.edu/projects/nfsv4/rfc/draft-ietf-nfsv4-acl-mapping-05.txt

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

When RichACLs are supported in the Linux kernel, I assume that POSIX
ACLs will still be available too. In that case, the kernel would enforce
the ACLs (just like it does now for POSIX ACLs) and we do not really
need to care about it (hopefully).

Thanks,
Niels
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20141217/32cf70f7/attachment.sig>