All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Theall <mtheall@linux.vnet.ibm.com>
To: "Seth Forshee" <seth.forshee@canonical.com>,
	fuse-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org,
	"Miklos Szeredi" <miklos@szeredi.hu>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Michael j Theall" <mtheall@us.ibm.com>,
	"Jean-Pierre André" <jean-pierre.andre@wanadoo.fr>
Subject: Re: [fuse-devel] [RFC v3 0/2] Support for posix acls in fuse
Date: Tue, 02 Aug 2016 10:13:58 -0500	[thread overview]
Message-ID: <1470150838.9444.7.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160802033931.GA33767@ubuntu-hedt>

On Mon, 2016-08-01 at 22:39 -0500, Seth Forshee wrote:
> On Mon, Aug 01, 2016 at 04:03:57PM -0700, Nikolaus Rath wrote:
> > 
> > On Aug 01 2016, Seth Forshee <seth.forshee@canonical.com> wrote:
> > > 
> > > There's also a problem with default acls that I'm not sure
> > > there's
> > > currently a solution for. As far as I can tell FUSE_CREATE
> > > doesn't give
> > > back any indication of whether an existing file was opened or a
> > > new file
> > > was created. Without knowing that I cannot know whether or not
> > > the inode
> > > should inherit default acls from its parent.
> > Would it be possible for the FUSE file system to implement this
> > inheritance by a dumb-copy of the ACL-related xattrs of the parent?
> > 
> > This would solve your problem. But in addition to that, it also
> > seems to
> > me that even if a file system uses default_permissions for ACL
> > handling,
> > it may want implement a different policy for permission
> > inheritance...
> In my opinion it's preferable for the kernel to handle all of this
> and
> for the filesystems to need only xattr support to get support for
> acls.
> 
> The inheritance behavior is standard for default acls. It shouldn't
> be
> left to individual filesystems to decide the inheritance policy.
> 
> Thanks,
> Seth

In case this has any bearing, my filesystem would in fact interpret the
ACLs from the xattrs in order to apply them to the backing filesystem
(which supports ACLs but through a non-xattr interface). In my
particular case, it would be okay for the kernel to assume the
inherited ACLs since it should be the same as if the kernel requested
the ACLs after creation.

Regards,
Michael Theall


  reply	other threads:[~2016-08-02 16:40 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
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     ` Michael Theall [this message]
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=1470150838.9444.7.camel@linux.vnet.ibm.com \
    --to=mtheall@linux.vnet.ibm.com \
    --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 \
    --cc=seth.forshee@canonical.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 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.