Re: Portable filesystem ACLs?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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.

Thanks,
Soumya


What do others think about this? Any suggestions, alternative solutions
or comments in general?

Thanks,
Niels



_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux