From: Andreas Gruenbacher <agruenba@redhat.com>
To: gluster-devel@gluster.org, ceph-devel@vger.kernel.org
Subject: Richacls
Date: Thu, 26 Feb 2015 16:54:42 +0100 [thread overview]
Message-ID: <54EF41C2.5080700@redhat.com> (raw)
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?
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.
[1] http://lwn.net/Articles/634870/
[2] http://www.bestbits.at/richacl/
Thanks,
Andreas
next reply other threads:[~2015-02-26 15:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-26 15:54 Andreas Gruenbacher [this message]
2015-02-26 17:14 ` [Gluster-devel] Richacls Niels de Vos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54EF41C2.5080700@redhat.com \
--to=agruenba@redhat.com \
--cc=ceph-devel@vger.kernel.org \
--cc=gluster-devel@gluster.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.