From: Andreas Gruenbacher <agruenba@redhat.com>
To: Jan Kara <jack@suse.cz>, "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-fsdevel@vger.kernel.org, lsf-pc@lists.linux-foundation.org
Subject: Re: [Lsf-pc] [LSF/MM ATTEND] Richacls
Date: Tue, 13 Jan 2015 16:07:47 +0100 [thread overview]
Message-ID: <54B534C3.3090608@redhat.com> (raw)
In-Reply-To: <20150113101435.GA28924@quack.suse.cz>
On 01/13/2015 11:14 AM, Jan Kara wrote:
>As far as I remember (and I'm sorry if I'm too explicit here) the main
> issue is to find a way of implementing the features necessary for RichACLs
> in a way acceptable for Al and Christoph Hellwig. I specifically remember
> Christoph having strong opinions on the rich ACL features as such.
I'm aware of two major kinds of issues: first, if the permission model
as implemented in the current (old) patch set makes sense and if a
simplified model isn't enough, and second, if richacls really need to be
represented differently than POSIX ACLs which are already in the kernel
(struct posix_acl).
I think the features that the permission model that the richacl patches
implement are needed and that a simplified model wouldn't be useful. As
far as the implementation goes, there are significant differences among
the two models (richacl entries can either allow or deny something, the
order of entries matters, and instead of having "access" as well as
default acls as separate objects, inheritance is determined by flags of
the acl and its entries). But that doesn't require that different
objects need to be used for representing the two kinds of acls: shoving
both models into the same object type would make the details slightly
more difficult to understand but those details would be somewhat hidden
at the "layer above" as well. I'll try if that approach holds any value.
Thanks,
Andreas
next prev parent reply other threads:[~2015-01-13 15:08 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1626890778.1513173.1421087867777.JavaMail.zimbra@redhat.com>
2015-01-12 21:06 ` [LSF/MM ATTEND] Richacls Andreas Gruenbacher
2015-01-12 21:54 ` Jeremy Allison
2015-01-12 22:30 ` J. Bruce Fields
2015-01-13 10:14 ` [Lsf-pc] " Jan Kara
2015-01-13 15:07 ` Andreas Gruenbacher [this message]
2015-01-13 16:48 ` Jeremy Allison
2015-01-13 17:23 ` Andreas Gruenbacher
2015-01-13 17:29 ` Jeremy Allison
2015-01-13 17:40 ` J. Bruce Fields
2015-01-13 18:04 ` Jeremy Allison
2015-01-13 19:53 ` Frank Filz
2015-01-13 20:24 ` 'J. Bruce Fields'
2015-01-13 20:26 ` Jeremy Allison
2015-01-13 20:30 ` Jeremy Allison
2015-01-13 20:35 ` Frank Filz
2015-01-14 7:57 ` Andreas Gruenbacher
2015-01-13 21:04 ` Jan Kara
2015-01-13 21:16 ` J. Bruce Fields
2015-01-13 21:20 ` Jeremy Allison
2015-01-13 21:27 ` Frank Filz
2015-01-13 21:31 ` Jan Kara
2015-01-14 8:53 ` Andreas Gruenbacher
2015-01-14 12:01 ` Jeff Layton
2015-01-14 16:11 ` J. Bruce Fields
2015-01-14 17:21 ` Frank Filz
2015-01-23 5:31 ` Steve French
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=54B534C3.3090608@redhat.com \
--to=agruenba@redhat.com \
--cc=bfields@fieldses.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).