Re: [Gluster-devel] Richacls

2015-02-26 Thread Justin Clift
On 26 Feb 2015, at 15:54, Andreas Gruenbacher agrue...@redhat.com wrote:
snip
 I've posted an updated version of the richacl kernel patches and
 user-space bits earlier today [1].  This should give anyone interested
 in the topic a chance to get richacls up and running locally, on ext4,

Is this kind of thing suitable for XFS too?

(note - I'm not that technically in depth any more, so more just curious)

:)

Regards and best wishes,

Justin Clift

--
GlusterFS - http://www.gluster.org

An open source, distributed file system scaling to several
petabytes, and handling thousands of clients.

My personal twitter: twitter.com/realjustinclift

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel


Re: [Gluster-devel] Richacls

2015-02-26 Thread Andreas Grünbacher
2015-02-26 17:21 GMT+01:00 Justin Clift jus...@gluster.org:
 Is this kind of thing suitable for XFS too?

Sure, ext4 is just the first file system supported.

Andreas
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel


Re: [Gluster-devel] Richacls

2015-02-26 Thread Niels de Vos
On Thu, Feb 26, 2015 at 04:54:42PM +0100, Andreas Gruenbacher wrote:
 Hi everyone,
 
 I've posted an updated version of the richacl kernel patches and
 user-space bits earlier today [1].  This should give anyone interested
 in the topic a chance to get richacls up and running locally, on ext4,
 to get a feeling of how they work.  See the richacl homepage [2] for
 instructions on getting started, some examples, and some bits of
 background information.
 
 Some of you are interested in supporting richacls in glusterfs and ceph.
  This will require richacl permission checking in user space; I would
 suggest to use librichacl for doing that.  There's a new
 richacl_permission() function there for that currently declared as follows:
 
   /**
* richacl_permission  -  check if a user has the requested access
* @acl:ACL of the file to check
* @owner:  Owner of the file
* @owning_group: Owning group of the file
* @user:   User ID of the accessing process
* @groups: Group IDs the accessing process is a member in
* @n_groups:   Number of entries in @groups
* @mask:   Requested permissions (ACE4_* mask flags)
*/
  bool richacl_permission(struct richacl *acl, uid_t owner,
  gid_t  owning_group, uid_t user,
  const gid_t *groups, int n_groups,
  unsigned int mask)
 
 Is this interface suitable?

Yes, that looks very usable to me.

 Note that full permission checking often requires more than just a
 single richacl_permission() check: for example, deleting files is
 restricted to the owner in sticky directories; other mechanisms like
 capabilities may play a role as well.
 
 Some documentation on how the various richacl permission bits are
 supposed to work can be found in the kernel patches.  In addition, the
 test cases in the richacl package are supposed to also document and test
 all the corner cases; they are not perfect yet though.
 
 Librichacl exports functions for converting from richacl extended
 attributes to librichacl's internal representation and back now.  This
 should allow to pass around the richacl xattr blobs and feed them to
 librichacl for permission checking and other richacl manipulations.

Great, that makes it much easier to implement support in the FUSE daemon
side of things.

Thanks for the update!
Niels


 
   [1] http://lwn.net/Articles/634870/
   [2] http://www.bestbits.at/richacl/
 
 Thanks,
 Andreas
 ___
 Gluster-devel mailing list
 Gluster-devel@gluster.org
 http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel