From: Michael Theall <mtheall@linux.vnet.ibm.com>
To: "Miklos Szeredi" <miklos@szeredi.hu>,
"Jean-Pierre André" <jean-pierre.andre@wanadoo.fr>
Cc: Andreas Gruenbacher <agruenba@redhat.com>,
fuse-devel <fuse-devel@lists.sourceforge.net>,
Seth Forshee <seth.forshee@canonical.com>,
Nikolaus Rath <Nikolaus@rath.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: [fuse-devel] [PATCH 0/2] Support for posix ACLs in fuse
Date: Wed, 21 Sep 2016 15:50:55 -0500 [thread overview]
Message-ID: <1474491055.1314.4.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAJfpegvnXGc9_nosLrBho1HKooPY9ZhK2u3gcVO8a6NKprndpA@mail.gmail.com>
On Wed, 2016-09-21 at 16:14 +0200, Miklos Szeredi wrote:
> On Wed, Sep 21, 2016 at 2:25 PM, Jean-Pierre André
> <jean-pierre.andre@wanadoo.fr> wrote:
>
> >
> > The code for Posix ACLs support within the kernel is
> > already present in ntfs-3g (just have to define the
> > macro KERNELACLS in order to disable the checks
> > within ntfs-3g and rely on the kernel ones).
> >
> > This however relies on assumptions I made a few years
> > back, and might be invalid now. I will at least have
> > to set some flag in the init callback.
> >
> > The ACLs are supposed to be set and retrieved through
> > the extended attributes system.posix_acl_access and
> > system.posix_acl_default. Recent posts about it in
> > this list mention "xattr handlers", do they mean
> > getxattr() and setxattr() on these extended attributes ?
> Right.
>
> >
> > Also the sync with the file mode is done natively,
> > as the ACLs and modes are translated to a single
> > object (an NTFS ACL). There is no need for fuse to
> > duplicate the mode to a ACL setting or conversely.
> >
> > Now the main problem for ntfs-3g is to migrate to
> > libfuse3, still keeping the compatibility with non-Linux
> > implementations (MacOSX, OpenIndiana, and others).
> > I have not done anything about it yet.
> >
> > Does the Posix ACL in-kernel support require libfuse3 ?
> Not really, the most important change (and apparently the only one
> that ntfs-3g cares about) will be the added capability flag, but it's
> trivial to add it to libfuse2.
>
> Thanks,
> Miklos
Hi,
I'm currently trying to port my code to take advantage of this. I've
found myself in sort of a catch-22 situation: I don't know whether to
pass default_permissions or not.
Right now, I support ACLs by not using default_permissions. However,
the FUSE_POSIX_ACL capability is only given when default_permissions is
turned on. If I unconditionally set FUSE_POSIX_ACL in the "want" flags,
the capability remains disabled if default_permissions is off.
I need to support ACLs on backlevel platforms with default_permissions
off, and the coming platforms with default_permissions on. How do you
suggest I determine whether to provide it or not?
Regards,
Michael Theall
next prev parent reply other threads:[~2016-09-21 20:51 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-29 13:46 [PATCH 0/2] Support for posix ACLs in fuse Seth Forshee
2016-08-29 13:46 ` [PATCH 1/2] fuse: Use generic xattr ops Seth Forshee
2016-08-29 13:46 ` [PATCH 2/2] fuse: Add posix ACL support Seth Forshee
2016-09-07 3:32 ` [PATCH 0/2] Support for posix ACLs in fuse Nikolaus Rath
2016-09-07 12:32 ` Seth Forshee
2016-09-21 8:30 ` Miklos Szeredi
2016-09-21 12:25 ` Jean-Pierre André
2016-09-21 14:14 ` Miklos Szeredi
2016-09-21 20:50 ` Michael Theall [this message]
2016-09-23 15:03 ` [fuse-devel] " Miklos Szeredi
2016-09-21 13:41 ` Seth Forshee
2016-09-21 13:57 ` Miklos Szeredi
2016-09-28 19:34 ` Seth Forshee
2016-09-21 15:40 ` Eric W. Biederman
2016-09-21 17:24 ` Andreas Grünbacher
2016-09-21 17:42 ` Eric W. Biederman
2016-09-21 19:00 ` Jeremy Allison
2016-09-21 21:08 ` Andreas Grünbacher
2016-09-21 21:28 ` Andreas Grünbacher
2016-09-23 9:01 ` Miklos Szeredi
2016-09-23 9:15 ` Andreas Grünbacher
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=1474491055.1314.4.camel@linux.vnet.ibm.com \
--to=mtheall@linux.vnet.ibm.com \
--cc=Nikolaus@rath.org \
--cc=agruenba@redhat.com \
--cc=fuse-devel@lists.sourceforge.net \
--cc=jean-pierre.andre@wanadoo.fr \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--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 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).