From: Seth Forshee <seth.forshee@canonical.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
fuse-devel <fuse-devel@lists.sourceforge.net>,
linux-fsdevel@vger.kernel.org,
"Michael j Theall" <mtheall@us.ibm.com>,
"Jean-Pierre André" <jean-pierre.andre@wanadoo.fr>,
"Nikolaus Rath" <Nikolaus@rath.org>
Subject: Re: [RFC v3 2/2] fuse: Add posix acl support
Date: Sat, 6 Aug 2016 22:46:31 -0500 [thread overview]
Message-ID: <20160807034631.GA135007@ubuntu-hedt> (raw)
In-Reply-To: <CAJfpegsvLwBh-si9FYMAg8xzb80urXetR0F45=qU36rk8CPHtQ@mail.gmail.com>
On Sat, Aug 06, 2016 at 11:09:54PM +0200, Miklos Szeredi wrote:
> On Sat, Aug 6, 2016 at 3:52 AM, Seth Forshee <seth.forshee@canonical.com> wrote:
> > On Fri, Aug 05, 2016 at 06:07:44PM -0500, Eric W. Biederman wrote:
> > What I'm not convinced of is that the userspace visible changes in
> > behavior won't break someone's software, even if they aren't really
> > getting acl enforcement.
>
> That's a key point. Backward compatibility is important, and not even
> hard to do because fuse can negotiate supported features with the
> userspace filesystem.
>
> So we can have a new FUSE_POSIX_ACL feature flag in INIT, sent if
> "default_permissions" is on.
>
> If not set in INIT reply just pass all xattrs through to the
> filesystem. Caching should not be done. Don't think about whether
> it's logical or not, or if anyone could use it for anything sane.
> Just do what we are doing currently. Translating uids still makes
> sense, but that's another story.
Translating uids is actually central to the differing positions that you
and Eric have. What Eric wants is for the only path for supporting posix
acls to be via the helpers, that way all concerns about translating uids
can be addressed there. If fuse is to allow the xattrs to be passed
directly through to the filesystem then there has to be a second
mechanism which translates the uids for that case.
> If the flag is set in INIT reply, then that means userspace filesystem
> wants handling of posix acl permission checking in kernel. It would
> also mean that caching of posix acl are allowed (lifetime linked to
> attribute lifetime).
>
> If filesystem wants to explicitly disable posix acl support, then it
> can reply EOPNOTSUPP to getxattr and setxattr on "system.posix_acl_*".
> Alternatively we can add a FUSE_NO_POSIX_ACL feature flag, that
> filesystem can return in reply to FUSE_POSIX_ACL.
>
> I agree that adding CONFIG_FUSE_FS_POSIX_ACL is probably not worth it,
> just make any such code dependent on CONFIG_FS_POSIX_ACL.
But CONFIG_FS_POSIX_ACL doesn't have an input prompt and thus isn't
displayed in menuconfig, etc. If that's what you want, fine, but it
seems like an unusual situation.
Thanks,
Seth
next prev parent reply other threads:[~2016-08-07 3:46 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-01 21:27 [RFC v3 0/2] Support for posix acls in fuse Seth Forshee
2016-08-01 21:27 ` [RFC v3 1/2] fuse: Use generic xattr ops Seth Forshee
2016-08-04 11:09 ` Miklos Szeredi
2016-08-04 14:12 ` Seth Forshee
2016-08-01 21:27 ` [RFC v3 2/2] fuse: Add posix acl support Seth Forshee
2016-08-04 12:11 ` Miklos Szeredi
[not found] ` <CAJfpegtzeJid8tHkz66scDcpCjNEEwtBb4m8MQqq7u+SCdj3dQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-08-04 12:40 ` Ravishankar N
2016-08-04 14:11 ` Seth Forshee
2016-08-05 23:07 ` Eric W. Biederman
2016-08-06 1:52 ` Seth Forshee
2016-08-06 21:09 ` Miklos Szeredi
2016-08-07 3:46 ` Seth Forshee [this message]
2016-08-07 12:59 ` Eric W. Biederman
[not found] ` <87popkrazt.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-08-07 13:51 ` Seth Forshee
2016-08-16 20:59 ` Seth Forshee
2016-08-17 12:01 ` Miklos Szeredi
2016-08-01 23:03 ` [RFC v3 0/2] Support for posix acls in fuse Nikolaus Rath
2016-08-02 3:39 ` Seth Forshee
2016-08-02 15:13 ` [fuse-devel] " Michael Theall
2016-08-09 0:00 ` Nikolaus Rath
2016-08-09 0:03 ` Nikolaus Rath
2016-08-09 0:27 ` Eric W. Biederman
2016-08-09 22:44 ` Nikolaus Rath
2016-08-09 7:06 ` Jean-Pierre André
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=20160807034631.GA135007@ubuntu-hedt \
--to=seth.forshee@canonical.com \
--cc=Nikolaus@rath.org \
--cc=ebiederm@xmission.com \
--cc=fuse-devel@lists.sourceforge.net \
--cc=jean-pierre.andre@wanadoo.fr \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mtheall@us.ibm.com \
/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).