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 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.