linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Seth Forshee <seth.forshee@canonical.com>
To: fuse-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org,
	Miklos Szeredi <miklos@szeredi.hu>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [RFC] fuse: Support posix ACLs
Date: Fri, 1 Jul 2016 14:58:56 -0500	[thread overview]
Message-ID: <20160701195856.GC67600@ubuntu-hedt> (raw)
In-Reply-To: <87k2h59my3.fsf@thinkpad.rath.org>

On Fri, Jul 01, 2016 at 12:29:24PM -0700, Nikolaus Rath wrote:
> On Jun 29 2016, Seth Forshee <seth.forshee@canonical.com> wrote:
> > Eric and I are working towards adding support for fuse mounts in
> > non-init user namespaces. Towards that end we'd like to add ACL support
> > to fuse as this will allow for a cleaner implementation overall. Below
> > is an initial patch to support this. I'd like to get some general
> > feedback on this patch and ask a couple of specific questions.
> >
> > There are some indications that fuse supports ACLs on the userspace side
> > when default_permissions is not used (though I'm not seeing how that
> > works). Will these changes conflict with that support, and if how do we
> > avoid those conflicts?
> >
> I think as long as the kernel interprets ACLs only if default_permission
> is used, you should be fine.

With !default_permission fuse never calls generic_permission so the
kernel won't enforce the acls regardless. For the purpose of user
namespace mounts it's still useful if the kernel intercepts them so that
the posix acl layer can do the uid/gid translation before passing it to
the filesystem. The xattrs still get sent on to the filesystem, however
cached acls if present would be used to satisfy reads of the acl xatts.

Thanks,
Seth

      reply	other threads:[~2016-07-01 20:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-29 19:07 [RFC] fuse: Support posix ACLs Seth Forshee
2016-06-29 19:24 ` Michael j Theall
     [not found]   ` <OFF8F0F486.DB2CEB73-ON86257FE1.006A1FF4-86257FE1.006A9703-8eTO7WVQ4XIsd+ienQ86orlN3bxYEBpz@public.gmane.org>
2016-06-29 19:52     ` Michael j Theall
2016-06-29 21:03       ` [fuse-devel] " Seth Forshee
2016-06-29 21:13         ` Michael j Theall
2016-06-29 20:18   ` [fuse-devel] " Eric W. Biederman
     [not found]     ` <87vb0rhhpr.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-06-29 20:35       ` Michael j Theall
2016-06-30  7:23     ` [fuse-devel] " Jean-Pierre André
2016-06-30 13:07     ` Seth Forshee
2016-06-30 16:25       ` Eric W. Biederman
2016-06-30 16:54         ` Seth Forshee
2016-07-01 19:37           ` Nikolaus Rath
2016-07-01 19:33     ` Nikolaus Rath
2016-07-01 19:49       ` Seth Forshee
2016-06-29 20:56   ` Seth Forshee
2016-06-30  7:13 ` Jean-Pierre André
2016-07-01 19:29 ` Nikolaus Rath
2016-07-01 19:58   ` Seth Forshee [this message]

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=20160701195856.GC67600@ubuntu-hedt \
    --to=seth.forshee@canonical.com \
    --cc=ebiederm@xmission.com \
    --cc=fuse-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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).