Support for richacl?

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Support for richacl?

Stef Bon-2
Hi,

since some time richacl support is added to the kernel. Is it also time to
add it to fuse?

Stef
------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Nikolaus Rath
On Dec 26 2015, Stef Bon <[hidden email]> wrote:
> Hi,
>
> since some time richacl support is added to the kernel. Is it also time to
> add it to fuse?

I think we should start with regular ACL support. What's needed is a
function (either in the fuse module or libfuse) to translate between
Unix permissions and extended attributes. Unfortunately it's not
sufficient for a file system to just implement "dumb"
setxattr/getxtattr/listxattr, because the file system must keep ACLs and
unix permissions in sync.

Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Stef Bon-2
Hi,

you mean with regular ACL support is to have a algoritme which translates
the xattributes (the name I do not have present) to acl's and to unix
permissions?

This is upto the filesystem, not to the library.

Stef
------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Stef Bon-2
I mean, it's possible to use the existing  ACCESS call in the filesystem
for implementing the posix acl access attributes?
Is it really required to add a new access algoritm in the library or the
kernel module?

Stef
------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Nikolaus Rath
In reply to this post by Stef Bon-2
On Dec 27 2015, Stef Bon <[hidden email]> wrote:
> Hi,
>
> you mean with regular ACL support is to have a algoritme which translates
> the xattributes (the name I do not have present) to acl's and to unix
> permissions?

Sort of. I mean an algorithm that translates between unix permissions
and ACLs (which are stored as extended attributes).

> This is upto the filesystem, not to the library.

Why? What's the point of having each FUSE file system reimplement this?
You could just as well argue that libfuse shouldn't exist at all,
because every file system can implement communication with the kernel
module itself.

Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Nikolaus Rath
In reply to this post by Stef Bon-2
On Dec 28 2015, Stef Bon <[hidden email]> wrote:
> I mean, it's possible to use the existing  ACCESS call in the filesystem
> for implementing the posix acl access attributes?

You could implement your own ACLL check for each handler (including
ACCESS), but I see little reason to do so. In most cases, a file system
can use the "default_permissions" option and leave it to the kernel to
do both ACL and unix permission checks.

> Is it really required to add a new access algoritm in the library or the
> kernel module?

I'm not sure what I mean, but I think you haven't understood my first
email.

Fuse filesystems don't need support for ACL checking, they need to be
able to keep ACLs and Unix permissions in sync. For example, 'cp -a
<foofile> <barfile>' will attempt to copy the ACL from foofile to
barfile. If that succeeds, it never copies the Unix permissions. So if
you FUSE fs doesn't know how to extract the appropriate Unix permissions
from the ACL on setxattr(), barfile will end up with default Unix
permissions instead of those from barfile.

The nicest solution for this would be if either the FUSE module or
libfuse would automatically do the ACL parsing, so that cp's setfacl()
call results in both a setxattr() and a (corresponding, automatically
generated)setattr() request for the file system.
 

Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Jean-Pierre André
Hi,

Nikolaus Rath wrote:

> On Dec 28 2015, Stef Bon <[hidden email]> wrote:
>> I mean, it's possible to use the existing  ACCESS call in the filesystem
>> for implementing the posix acl access attributes?
>
> You could implement your own ACLL check for each handler (including
> ACCESS), but I see little reason to do so. In most cases, a file system
> can use the "default_permissions" option and leave it to the kernel to
> do both ACL and unix permission checks.
>
>> Is it really required to add a new access algoritm in the library or the
>> kernel module?
>
> I'm not sure what I mean, but I think you haven't understood my first
> email.
>
> Fuse filesystems don't need support for ACL checking, they need to be
> able to keep ACLs and Unix permissions in sync. For example, 'cp -a
> <foofile> <barfile>' will attempt to copy the ACL from foofile to
> barfile. If that succeeds, it never copies the Unix permissions. So if
> you FUSE fs doesn't know how to extract the appropriate Unix permissions
> from the ACL on setxattr(), barfile will end up with default Unix
> permissions instead of those from barfile.

AFAIR, cp requests both copying the acl and the
permissions, so this should not be a problem.

However, there was (not checked recently) a problem
with the cache : if you set permissions with setfacl
(such as "setfacl -m u::7,g::5,o::5 myfile"),
the previous permissions for myfile in the cache
are still used, even if the file system does the
translation job.
On the low-level interface, you can invalidate the
cache by fuse_lowlevel_notify_inval_inode(), but
you cannot do so on the high-level interface...

>
> The nicest solution for this would be if either the FUSE module or
> libfuse would automatically do the ACL parsing, so that cp's setfacl()
> call results in both a setxattr() and a (corresponding, automatically
> generated)setattr() request for the file system.
>
>
> Best,
> -Nikolaus
>


------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Stef Bon-2
In reply to this post by Nikolaus Rath
2015-12-28 17:44 GMT+01:00 Nikolaus Rath <[hidden email]>:

> > This is upto the filesystem, not to the library.
>
> Why? What's the point of having each FUSE file system reimplement this?
> You could just as well argue that libfuse shouldn't exist at all,
> because every file system can implement communication with the kernel
> module itself.


You say that we just as well argue that libfuse should not exist at all.
This is not what I want and mean.  I think that there are and will not be
many
filesystems using acl checking based upon xattr. So to add it to
the general libfuse and/or fuse module is questionable, it will make the
library
much more complicated and possibly has performance consequenses, while not
much
filesystems will use it.

In stead I would like to provide examples of filesystems which offer a
basic ACL checking
so people wanting to write a filesystem have an example how to do this.

I'm pro a general library, not offering too much special features.

Stef
------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Nikolaus Rath
In reply to this post by Jean-Pierre André
On Dec 28 2015, Jean-Pierre André <[hidden email]> wrote:

> Hi,
>
> Nikolaus Rath wrote:
>> On Dec 28 2015, Stef Bon <[hidden email]> wrote:
>>> I mean, it's possible to use the existing  ACCESS call in the filesystem
>>> for implementing the posix acl access attributes?
>>
>> You could implement your own ACLL check for each handler (including
>> ACCESS), but I see little reason to do so. In most cases, a file system
>> can use the "default_permissions" option and leave it to the kernel to
>> do both ACL and unix permission checks.
>>
>>> Is it really required to add a new access algoritm in the library or the
>>> kernel module?
>>
>> I'm not sure what I mean, but I think you haven't understood my first
>> email.
>>
>> Fuse filesystems don't need support for ACL checking, they need to be
>> able to keep ACLs and Unix permissions in sync. For example, 'cp -a
>> <foofile> <barfile>' will attempt to copy the ACL from foofile to
>> barfile. If that succeeds, it never copies the Unix permissions. So if
>> you FUSE fs doesn't know how to extract the appropriate Unix permissions
>> from the ACL on setxattr(), barfile will end up with default Unix
>> permissions instead of those from barfile.
>
> AFAIR, cp requests both copying the acl and the
> permissions, so this should not be a problem.

That would be nice, but I ran into exactly this problem a few years
ago. And looking at lib/copy-acl.c in coreutils 8.23, it hasn't changed
(not that I'd expect it to, cp's behavior is correct):

,----
| [...]
| /* Copy access control lists from one file to another. If SOURCE_DESC is
|    a valid file descriptor, use file descriptor operations, else use
|    filename based operations on SRC_NAME. Likewise for DEST_DESC and
|    DST_NAME.
|    If access control lists are not available, fchmod the target file to
|    MODE.  Also sets the non-permission bits of the destination file
|    (S_ISUID, S_ISGID, S_ISVTX) to those from MODE if any are set.
|    Return 0 if successful, otherwise output a diagnostic and return a
|    negative error code.  */
|
| int
| copy_acl (const char *src_name, int source_desc, const char *dst_name,
|           int dest_desc, mode_t mode)
| {
|   int ret = qcopy_acl (src_name, source_desc, dst_name, dest_desc,
| mode);
| [...]
`----

Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Nikolaus Rath
In reply to this post by Stef Bon-2
On Dec 28 2015, Stef Bon <[hidden email]> wrote:

> 2015-12-28 17:44 GMT+01:00 Nikolaus Rath <[hidden email]>:
>
>> > This is upto the filesystem, not to the library.
>>
>> Why? What's the point of having each FUSE file system reimplement this?
>> You could just as well argue that libfuse shouldn't exist at all,
>> because every file system can implement communication with the kernel
>> module itself.
>
>
> You say that we just as well argue that libfuse should not exist at
> all.  This is not what I want and mean.  I think that there are and
> will not be many filesystems using acl checking based upon xattr.

I should hope so, because that task is much better done by the
kernel. But FUSE file systems should be able to support storing ACLs
without jumping through hoops like having to parse xattrs.

Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Michael j Theall

I did submit a kernel patch to add POSIX ACL (via extended attributes) to
the FUSE kernel module last year. Unfortunately, it was somewhat ignored
with some unanswered questions. Essentially, I was told that the kernel
module should be upcalling access() for every dentry lookup, but I found
that this was false, and so my filesystem could not rely on knowing
permissions for each path component since an inode could have more than one
path. Additionally, default_permissions doesn't check POSIX ACLs. I had to
resort to adding an 'acl' option to my filesystem which turns on POSIX ACL
support and turns off default_permissions which means I get a lot of
lookups which dramatically slows down my filesystem. I later opened another
question asking about whether it is feasible to use a dentry identifier
instead of an inode identifier in order to distinguish paths and whether
that makes an inode from different paths look like different files (cache
coherency problems?), but nobody responded to that either.

I definitely could use POSIX ACL support built-in to FUSE and would be
happy to contribute, even if that means my RHEL customers have to wait
another 3-5 years to be able to use it.

Regards,
Michael Theall

Nikolaus Rath <[hidden email]> wrote on 12/28/2015 03:36:23 PM:

> From: Nikolaus Rath <[hidden email]>
> To: [hidden email]
> Date: 12/28/2015 03:37 PM
> Subject: Re: [fuse-devel] Support for richacl?
>
> On Dec 28 2015, Stef Bon <stefbon-
> [hidden email]> wrote:
> > 2015-12-28 17:44 GMT+01:00 Nikolaus Rath <Nikolaus-
> [hidden email]>:
> >
> >> > This is upto the filesystem, not to the library.
> >>
> >> Why? What's the point of having each FUSE file system reimplement
this?

> >> You could just as well argue that libfuse shouldn't exist at all,
> >> because every file system can implement communication with the kernel
> >> module itself.
> >
> >
> > You say that we just as well argue that libfuse should not exist at
> > all.  This is not what I want and mean.  I think that there are and
> > will not be many filesystems using acl checking based upon xattr.
>
> I should hope so, because that task is much better done by the
> kernel. But FUSE file systems should be able to support storing ACLs
> without jumping through hoops like having to parse xattrs.
>
> Best,
> -Nikolaus
>
> --
> GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
> Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
>
>              »Time flies like an arrow, fruit flies like a Banana.«
>
>
------------------------------------------------------------------------------

> _______________________________________________
> fuse-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/fuse-devel
------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Stef Bon-2
In reply to this post by Nikolaus Rath
2015-12-28 22:36 GMT+01:00 Nikolaus Rath <[hidden email]>:

> > You say that we just as well argue that libfuse should not exist at
> > all.  This is not what I want and mean.  I think that there are and
> > will not be many filesystems using acl checking based upon xattr.
>
> I should hope so, because that task is much better done by the
> kernel. But FUSE file systems should be able to support storing ACLs
> without jumping through hoops like having to parse xattrs.
>

I'm afraid you miss my point. Because there will be not much filesystems
using permissions checking using xattr
my point is that this checking should not be done in the library. Agree?

I do not understand it anymore. What is meant here by support for regular
ACL's?
Now I need some oversight of what works now and what does not work yet.

a. if a filesystem provides the system.posix_acl_access and
system.posix_acl_default attributes, does the kernel
already check acl's using these?

b. when copy a file, you say that cp will not copy the unix
mode/permissions to the new file, if the ACL's are available. Is that
really the case?
Isn't it the case that when copying the file the unix mode is copied (using
setattr) AND the relevant Xattr using setxattr?

Please feel free to add more subject's which have to do with making ACL's
work.

Stef
------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Nikolaus Rath
In reply to this post by Michael j Theall
On Dec 29 2015, "Michael j Theall" <mtheall-r/[hidden email]> wrote:
> I did submit a kernel patch to add POSIX ACL (via extended attributes) to
> the FUSE kernel module last year.

Unfortunately I can't commit or sign-off changes to the FUSE kernel
module, but I'm interested in seeing the patch. Could you repost?

> Unfortunately, it was somewhat ignored with some unanswered
> questions. Essentially, I was told that the kernel module should be
> upcalling access() for every dentry lookup, but I found that this was
> false, and so my filesystem could not rely on knowing permissions for
> each path component since an inode could have more than one path.

I don't quite follow. What do you mean with upcalling?

> Additionally, default_permissions doesn't check POSIX ACLs.
[...]

Oh, are you sure? I thought it did (though I don't remember explicitly
checking it). That should definitely be fixed as well then.


Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Nikolaus Rath
In reply to this post by Stef Bon-2
On Dec 29 2015, Stef Bon <[hidden email]> wrote:

> 2015-12-28 22:36 GMT+01:00 Nikolaus Rath <[hidden email]>:
>
>> > You say that we just as well argue that libfuse should not exist at
>> > all.  This is not what I want and mean.  I think that there are and
>> > will not be many filesystems using acl checking based upon xattr.
>>
>> I should hope so, because that task is much better done by the
>> kernel. But FUSE file systems should be able to support storing ACLs
>> without jumping through hoops like having to parse xattrs.
>>
>
> I'm afraid you miss my point. Because there will be not much
> filesystems using permissions checking using xattr my point is that
> this checking should not be done in the library [...]

Judging from our history on this list, I don't think there's much chance
that we'll ever understand each other, so I'll refrain from further
comments. No offense intended.

Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Nikolaus Rath
In reply to this post by Stef Bon-2
(I still couldn't resist to answer these to specific questions)

On Dec 29 2015, Stef Bon <[hidden email]> wrote:
> a. if a filesystem provides the system.posix_acl_access and
> system.posix_acl_default attributes, does the kernel
> already check acl's using these?

I thought that, if default_permissions is used, it does. But I may have
been wrong, since Michael Theall just reported the opposite.

> b. when copy a file, you say that cp will not copy the unix
> mode/permissions to the new file, if the ACL's are available. Is that
> really the case?

Yes, see my other mail with the relevant source code.

> Isn't it the case that when copying the file the unix mode is copied (using
> setattr) AND the relevant Xattr using setxattr?

No.

Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Stef Bon-2
2015-12-29 17:58 GMT+01:00 Nikolaus Rath <[hidden email]>:

> (I still couldn't resist to answer these to specific questions)
>
> On Dec 29 2015, Stef Bon <[hidden email]>
> wrote:
> > a. if a filesystem provides the system.posix_acl_access and
> > system.posix_acl_default attributes, does the kernel
> > already check acl's using these?
>
> I thought that, if default_permissions is used, it does. But I may have
> been wrong, since Michael Theall just reported the opposite.
>

Ok some extra reasearch is required. Somewhere in VFS there should be some
check. How do filesystems like ext2/3/4 deal with this?

> b. when copy a file, you say that cp will not copy the unix
> > mode/permissions to the new file, if the ACL's are available. Is that
> > really the case?
>
> Yes, see my other mail with the relevant source code.
>
> > Isn't it the case that when copying the file the unix mode is copied
> (using
> > setattr) AND the relevant Xattr using setxattr?
>
> No.
>
>
Ok I had to think this over, but sounds ok. First I thought this can't be
right.

Stef
------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Jean-Pierre André
Hi,

Stef Bon wrote:

> 2015-12-29 17:58 GMT+01:00 Nikolaus Rath <[hidden email]>:
>
>> (I still couldn't resist to answer these to specific questions)
>>
>> On Dec 29 2015, Stef Bon <[hidden email]>
>> wrote:
>>> a. if a filesystem provides the system.posix_acl_access and
>>> system.posix_acl_default attributes, does the kernel
>>> already check acl's using these?
>>
>> I thought that, if default_permissions is used, it does. But I may have
>> been wrong, since Michael Theall just reported the opposite.
>>
>
> Ok some extra reasearch is required. Somewhere in VFS there should be some
> check. How do filesystems like ext2/3/4 deal with this?

A proposal for inserting acl checks in the fuse kernel
module when default_permissions is set was posted to this
list by Steven James, see :

http://article.gmane.org/gmane.comp.file-systems.fuse.devel/5651

I have used a fuse kernel module with this patch for some
time, and it worked well.

There still is an option in ntfs-3g to rely on it for Posix
acl checks. These are obviously more efficient than checks
in user space as is usually done in ntfs-3g.

>
>> b. when copy a file, you say that cp will not copy the unix
>>> mode/permissions to the new file, if the ACL's are available. Is that
>>> really the case?
>>
>> Yes, see my other mail with the relevant source code.
>>
>>> Isn't it the case that when copying the file the unix mode is copied
>> (using
>>> setattr) AND the relevant Xattr using setxattr?
>>
>> No.
>>
>>
> Ok I had to think this over, but sounds ok. First I thought this can't be
> right.
>
> Stef
> ------------------------------------------------------------------------------
> _______________________________________________
> fuse-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/fuse-devel
>


------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Stef Bon-2
In reply to this post by Stef Bon-2
Hi,

the posix acl using xattr are defined in
<kernel_source>/include/linux/posix_acl_xattr.h and
and some generic functions are in <source>/fs/posix_acl.c, with for example
posix_acl_permissions (lin 311 with linux 4.1.2.

The different filesystems like ext2/3/4 have their own handlers of xattr.
The kernel module does not have such handlers yet. These handlers (like
ext2_get_acl) are assigned to the .get_acl call in dir_inode_operations and
inode_operations in fs/ext2/namei.h.

When writing this post Jean_Pierre Andre posts about a patch from  Steven
James from 2008 (!), and it looks good.

Stef
------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Jean-Pierre André
In reply to this post by Jean-Pierre André
Hi,

I have found a few notes about using the patch by Steven James :

I tested compiling alsa, which led to creating and
accessing a lot of files (this was with kernel 2.6.30) :

Checking in user space (without the patch) : 52.68s
Checking in the kernel (using the patch) : 47.04s

These measurements were made with the fuse cache disabled,
when enabling it, the figures came down to 31.30s and 26.50s,
but the checks were broken as could be seen in the following
scenario :

# Using the low level interface of fuse, with use of ACLs
# intended to be checked in the kernel, but not related to
# access control
rm -rf trydir
mkdir trydir
echo file > trydir/file
ls -l trydir/file
setfacl -m 'u::7,g::5,o::5' trydir/file
ls -l trydir/file
sleep 1
ls -l trydir/file

-rw-r--r-- 1 root root 5 2009-09-12 12:02 trydir/file
-rw-r--r-- 1 root root 5 2009-09-12 12:02 trydir/file
-rwxr-xr-x 1 root root 5 2009-09-12 12:02 trydir/file


Jean-Pierre André wrote:

> Hi,
>
> Stef Bon wrote:
>> 2015-12-29 17:58 GMT+01:00 Nikolaus Rath <[hidden email]>:
>>
>>> (I still couldn't resist to answer these to specific questions)
>>>
>>> On Dec 29 2015, Stef Bon <[hidden email]>
>>> wrote:
>>>> a. if a filesystem provides the system.posix_acl_access and
>>>> system.posix_acl_default attributes, does the kernel
>>>> already check acl's using these?
>>>
>>> I thought that, if default_permissions is used, it does. But I may have
>>> been wrong, since Michael Theall just reported the opposite.
>>>
>>
>> Ok some extra reasearch is required. Somewhere in VFS there should be some
>> check. How do filesystems like ext2/3/4 deal with this?
>
> A proposal for inserting acl checks in the fuse kernel
> module when default_permissions is set was posted to this
> list by Steven James, see :
>
> http://article.gmane.org/gmane.comp.file-systems.fuse.devel/5651
>
> I have used a fuse kernel module with this patch for some
> time, and it worked well.
>
> There still is an option in ntfs-3g to rely on it for Posix
> acl checks. These are obviously more efficient than checks
> in user space as is usually done in ntfs-3g.
>
>>
>>> b. when copy a file, you say that cp will not copy the unix
>>>> mode/permissions to the new file, if the ACL's are available. Is that
>>>> really the case?
>>>
>>> Yes, see my other mail with the relevant source code.
>>>
>>>> Isn't it the case that when copying the file the unix mode is copied
>>> (using
>>>> setattr) AND the relevant Xattr using setxattr?
>>>
>>> No.
>>>
>>>
>> Ok I had to think this over, but sounds ok. First I thought this can't be
>> right.
>>
>> Stef
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> fuse-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/fuse-devel
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> fuse-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/fuse-devel
>



------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Support for richacl?

Stef Bon-2
Hi,

the patch looks ok, but the call

int err = generic_permission(inode, mask, fuse_check_acl);

does not exist anymore. In the kernel (in 4.1.2 at least) the function
does not call the acl function:

int generic_permission(struct inode *inode, int mask);

So what's your kernel Jean-Pierre? Must be something 2.7..

Stef

------------------------------------------------------------------------------
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
12