Should ACLs updates affect permission bits?

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

Should ACLs updates affect permission bits?

Nikolaus Rath
Hello,

Some programs, like cp -a, seem to rely on the file system to
automagically convert the representable part of ACLs to permission bits.

For example, if a file "src" with mode 664 is copied using "cp -a src
dst", then cp creates the destination file with

open("dst", O_WRONLY|O_CREAT|O_EXCL, 0600)

and then executes

fsetxattr(4, "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x06\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0)

on the target. If this fails, it falls back on

fchmod(4, 0100664)


Now, on my low-level FUSE file system with xattr support, this results
with the destination file having the wrong permission bits (600), but
the correct ACL (664).

Doing the same thing on ext4, both ACL and permission bits are set
correctly to 664, even though cp never issued an fchmod call.

Is the file system supposed to apply ACL updates to permission bits as
well? If so, shouldn't this really be done in the kernel, or at least by
FUSE? Otherwise every FUSE file system would be required to implement
its own ACL parser and ACL-to-permission-bit converter.


Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

Jean-Pierre André
Hi,

Nikolaus Rath wrote:

> Hello,
>
> Some programs, like cp -a, seem to rely on the file system to
> automagically convert the representable part of ACLs to permission bits.
>
> For example, if a file "src" with mode 664 is copied using "cp -a src
> dst", then cp creates the destination file with
>
> open("dst", O_WRONLY|O_CREAT|O_EXCL, 0600)
>
> and then executes
>
> fsetxattr(4, "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x06\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0)
>
> on the target. If this fails, it falls back on
>
> fchmod(4, 0100664)
>
>
> Now, on my low-level FUSE file system with xattr support, this results
> with the destination file having the wrong permission bits (600), but
> the correct ACL (664).

IMHO, there should only be a (visible) set of permission bits.
The values returned by stat() and getfacl() have to be the
same.

 From Posix draft PSSG/D17 (1997, never became a standard)

2.3.2.1

The file permission bits of a file contain read, write and
execute/search permissions for the file owner class, file
group class and file other class.

*These bits* are set at file creation by open(), creat(),
mkdir() and mkfifo(). They are changed by chmod(), and
if {POSIX_ACL] is defined, acl_set_file() and acl_set_fd().
These bits are read by stat(), and fstat().

Regards

Jean-Pierre


> Doing the same thing on ext4, both ACL and permission bits are set
> correctly to 664, even though cp never issued an fchmod call.
>
> Is the file system supposed to apply ACL updates to permission bits as
> well? If so, shouldn't this really be done in the kernel, or at least by
> FUSE? Otherwise every FUSE file system would be required to implement
> its own ACL parser and ACL-to-permission-bit converter.
>
>
> Best,
>
>     -Nikolaus
>



------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

Nikolaus Rath
Jean-Pierre <[hidden email]> writes:

> Hi,
>
> Nikolaus Rath wrote:
>> Hello,
>>
>> Some programs, like cp -a, seem to rely on the file system to
>> automagically convert the representable part of ACLs to permission bits.
>>
>> For example, if a file "src" with mode 664 is copied using "cp -a src
>> dst", then cp creates the destination file with
>>
>> open("dst", O_WRONLY|O_CREAT|O_EXCL, 0600)
>>
>> and then executes
>>
>> fsetxattr(4, "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x06\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0)
>>
>> on the target. If this fails, it falls back on
>>
>> fchmod(4, 0100664)
>>
>>
>> Now, on my low-level FUSE file system with xattr support, this results
>> with the destination file having the wrong permission bits (600), but
>> the correct ACL (664).
>
> IMHO, there should only be a (visible) set of permission bits.
> The values returned by stat() and getfacl() have to be the
> same.
>
>  From Posix draft PSSG/D17 (1997, never became a standard)
>
> 2.3.2.1
>
> The file permission bits of a file contain read, write and
> execute/search permissions for the file owner class, file
> group class and file other class.
>
> *These bits* are set at file creation by open(), creat(),
> mkdir() and mkfifo(). They are changed by chmod(), and
> if {POSIX_ACL] is defined, acl_set_file() and acl_set_fd().
> These bits are read by stat(), and fstat().
>

Yes, that's pretty clear, thanks for the reference.

But then the file system really has to be able to parse ACL extended
attribute values, correct? So it would seem to me that the best place to
do that would really be in FUSE itself, so that it's available to all
FUSE file systems.

Best,

  -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

------------------------------------------------------------------------------
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

Feng Shuo-2
Nikolaus,

Can you have a try to do this in your own implementation (change the
mode internally), and see if FUSE can return the correct file mode? I
looked into FUSE code. It seems not revalidate the file mode after the
setxattr:

http://lxr.linux.no/linux+v3.7.3/fs/fuse/dir.c#L1508

This means FUSE might keep the old file mode untill it got expired.
IMO, FUSE should either call posix_acl_equiv_mode() and then
setattr():

http://lxr.linux.no/linux+v3.7.2/fs/posix_acl.c#L149

Or at least invalidate the inode attribute after the setxattr() call.

On Fri, Jan 18, 2013 at 11:06 AM, Nikolaus Rath <[hidden email]> wrote:

> Jean-Pierre <[hidden email]> writes:
>> Hi,
>>
>> Nikolaus Rath wrote:
>>> Hello,
>>>
>>> Some programs, like cp -a, seem to rely on the file system to
>>> automagically convert the representable part of ACLs to permission bits.
>>>
>>> For example, if a file "src" with mode 664 is copied using "cp -a src
>>> dst", then cp creates the destination file with
>>>
>>> open("dst", O_WRONLY|O_CREAT|O_EXCL, 0600)
>>>
>>> and then executes
>>>
>>> fsetxattr(4, "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x06\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0)
>>>
>>> on the target. If this fails, it falls back on
>>>
>>> fchmod(4, 0100664)
>>>
>>>
>>> Now, on my low-level FUSE file system with xattr support, this results
>>> with the destination file having the wrong permission bits (600), but
>>> the correct ACL (664).
>>
>> IMHO, there should only be a (visible) set of permission bits.
>> The values returned by stat() and getfacl() have to be the
>> same.
>>
>>  From Posix draft PSSG/D17 (1997, never became a standard)
>>
>> 2.3.2.1
>>
>> The file permission bits of a file contain read, write and
>> execute/search permissions for the file owner class, file
>> group class and file other class.
>>
>> *These bits* are set at file creation by open(), creat(),
>> mkdir() and mkfifo(). They are changed by chmod(), and
>> if {POSIX_ACL] is defined, acl_set_file() and acl_set_fd().
>> These bits are read by stat(), and fstat().
>>
>
> Yes, that's pretty clear, thanks for the reference.
>
> But then the file system really has to be able to parse ACL extended
> attribute values, correct? So it would seem to me that the best place to
> do that would really be in FUSE itself, so that it's available to all
> FUSE file systems.
>
> Best,
>
>   -Nikolaus
>
> --
>  »Time flies like an arrow, fruit flies like a Banana.«
>
>   PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C
>
> ------------------------------------------------------------------------------
> Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
> much more. Get web development skills now with LearnDevNow -
> 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
> SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122812
> _______________________________________________
> fuse-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/fuse-devel



--
Feng Shuo
Tel: (86)10-59851155-2116
Fax: (86)10-59851155-2008
Tianjin Zhongke Blue Whale Information Technologies Co., Ltd
10th Floor, Tower A, The GATE building, No. 19 Zhong-guan-cun Avenue
Haidian District, Beijing, China
Postcode 100080

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

Nikolaus Rath
Feng Shuo <[hidden email]> writes:

>
> On Fri, Jan 18, 2013 at 11:06 AM, Nikolaus Rath <[hidden email]> wrote:
>> Jean-Pierre <[hidden email]> writes:
>>> Hi,
>>>
>>> Nikolaus Rath wrote:
>>>> Hello,
>>>>
>>>> Some programs, like cp -a, seem to rely on the file system to
>>>> automagically convert the representable part of ACLs to permission bits.
>>>>
>>>> For example, if a file "src" with mode 664 is copied using "cp -a src
>>>> dst", then cp creates the destination file with
>>>>
>>>> open("dst", O_WRONLY|O_CREAT|O_EXCL, 0600)
>>>>
>>>> and then executes
>>>>
>>>> fsetxattr(4, "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x06\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0)
>>>>
>>>> on the target. If this fails, it falls back on
>>>>
>>>> fchmod(4, 0100664)
>>>>
>>>>
>>>> Now, on my low-level FUSE file system with xattr support, this results
>>>> with the destination file having the wrong permission bits (600), but
>>>> the correct ACL (664).
>>>
>>> IMHO, there should only be a (visible) set of permission bits.
>>> The values returned by stat() and getfacl() have to be the
>>> same.
>>>
>>>  From Posix draft PSSG/D17 (1997, never became a standard)
>>>
>>> 2.3.2.1
>>>
>>> The file permission bits of a file contain read, write and
>>> execute/search permissions for the file owner class, file
>>> group class and file other class.
>>>
>>> *These bits* are set at file creation by open(), creat(),
>>> mkdir() and mkfifo(). They are changed by chmod(), and
>>> if {POSIX_ACL] is defined, acl_set_file() and acl_set_fd().
>>> These bits are read by stat(), and fstat().
>>>
>>
>> Yes, that's pretty clear, thanks for the reference.
>>
>> But then the file system really has to be able to parse ACL extended
>> attribute values, correct? So it would seem to me that the best place to
>> do that would really be in FUSE itself, so that it's available to all
>> FUSE file systems.
>
> Nikolaus,
>
> Can you have a try to do this in your own implementation (change the
> mode internally), and see if FUSE can return the correct file mode? I
> looked into FUSE code. It seems not revalidate the file mode after the
> setxattr:
>
> http://lxr.linux.no/linux+v3.7.3/fs/fuse/dir.c#L1508
>
> This means FUSE might keep the old file mode untill it got expired.
> IMO, FUSE should either call posix_acl_equiv_mode() and then
> setattr():
>
> http://lxr.linux.no/linux+v3.7.2/fs/posix_acl.c#L149
>
> Or at least invalidate the inode attribute after the setxattr() call.

Yes, fuse does not reivalidate the file mode after setxattr() calls (at
least with Kernel 3.2 and fuse 2.9).

I'll patch up some handler code in my file system based on
posix_acl_equiv_mode (thanks for the link!) and an explicit
fuse_lowlevel_notify_inval_inode call.


I agree that FUSE should call posix_acl_equiv_mode(), followed by
setattr() and (only if necessary) setxattr().


Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

Miklos Szeredi
On Tue, Jan 22, 2013 at 3:23 AM, Nikolaus Rath <[hidden email]> wrote:

> Yes, fuse does not reivalidate the file mode after setxattr() calls (at
> least with Kernel 3.2 and fuse 2.9).
>
> I'll patch up some handler code in my file system based on
> posix_acl_equiv_mode (thanks for the link!) and an explicit
> fuse_lowlevel_notify_inval_inode call.
>
>
> I agree that FUSE should call posix_acl_equiv_mode(), followed by
> setattr() and (only if necessary) setxattr().

FUSE kernel code doesn't support POSIX ACL's at all presently.

Adding ACL support would make sense, and with that the reported bug
would be fixed.

With ACL support turned off (as presently) then I think the current
behavior is fine: the kernel should just pass unmodified xattrs to
userspace.

Thanks,
Miklos

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

Feng Shuo-2
Hi Miklos,

Yes, I think it will be nice to keep all xattrs opaque to FUSE kernel
because this will keep a clean and unitifed kernel/user space
interface, but it will still be necessary to invalid the inode by
fuse_invalidate_attr() after setxattr. This will make the kernel
reload the "i_mode" to the user space ACL implementations possible.


On Tue, Jan 22, 2013 at 9:50 PM, Miklos Szeredi <[hidden email]> wrote:

> On Tue, Jan 22, 2013 at 3:23 AM, Nikolaus Rath <[hidden email]> wrote:
>> Yes, fuse does not reivalidate the file mode after setxattr() calls (at
>> least with Kernel 3.2 and fuse 2.9).
>>
>> I'll patch up some handler code in my file system based on
>> posix_acl_equiv_mode (thanks for the link!) and an explicit
>> fuse_lowlevel_notify_inval_inode call.
>>
>>
>> I agree that FUSE should call posix_acl_equiv_mode(), followed by
>> setattr() and (only if necessary) setxattr().
>
> FUSE kernel code doesn't support POSIX ACL's at all presently.
>
> Adding ACL support would make sense, and with that the reported bug
> would be fixed.
>
> With ACL support turned off (as presently) then I think the current
> behavior is fine: the kernel should just pass unmodified xattrs to
> userspace.
>
> Thanks,
> Miklos
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d
> _______________________________________________
> fuse-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/fuse-devel



--
Feng Shuo
Tel: (86)10-59851155-2116
Fax: (86)10-59851155-2008
Tianjin Zhongke Blue Whale Information Technologies Co., Ltd
10th Floor, Tower A, The GATE building, No. 19 Zhong-guan-cun Avenue
Haidian District, Beijing, China
Postcode 100080

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

Nikolaus Rath
In reply to this post by Miklos Szeredi
Miklos Szeredi <[hidden email]> writes:

> On Tue, Jan 22, 2013 at 3:23 AM, Nikolaus Rath <[hidden email]> wrote:
>> Yes, fuse does not reivalidate the file mode after setxattr() calls (at
>> least with Kernel 3.2 and fuse 2.9).
>>
>> I'll patch up some handler code in my file system based on
>> posix_acl_equiv_mode (thanks for the link!) and an explicit
>> fuse_lowlevel_notify_inval_inode call.
>>
>>
>> I agree that FUSE should call posix_acl_equiv_mode(), followed by
>> setattr() and (only if necessary) setxattr().
>
> FUSE kernel code doesn't support POSIX ACL's at all presently.
>
> Adding ACL support would make sense, and with that the reported bug
> would be fixed.
>
> With ACL support turned off (as presently) then I think the current
> behavior is fine: the kernel should just pass unmodified xattrs to
> userspace.

Hi Miklos,

What do you mean with "ACL support turned off"? Presently a "cp -a" will
call setfacl() on a FUSE file system, the call will be forwarded to the
setxattr() handler, and to cp things will appear to work (with the
exception that the permission bits will not get updated).

The only workaround seems to be to explicitly returning ENOTSUP for any
attempt to write the system.posix_acl_* extended attributes.


Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

Nikolaus Rath
In reply to this post by Nikolaus Rath


Nikolaus Rath <[hidden email]> writes:

> Feng Shuo <[hidden email]> writes:
>>
>> On Fri, Jan 18, 2013 at 11:06 AM, Nikolaus Rath <[hidden email]> wrote:
>>> Jean-Pierre <[hidden email]> writes:
>>>> Hi,
>>>>
>>>> Nikolaus Rath wrote:
>>>>> Hello,
>>>>>
>>>>> Some programs, like cp -a, seem to rely on the file system to
>>>>> automagically convert the representable part of ACLs to permission bits.
>>>>>
>>>>> For example, if a file "src" with mode 664 is copied using "cp -a src
>>>>> dst", then cp creates the destination file with
>>>>>
>>>>> open("dst", O_WRONLY|O_CREAT|O_EXCL, 0600)
>>>>>
>>>>> and then executes
>>>>>
>>>>> fsetxattr(4, "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x06\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0)
>>>>>
>>>>> on the target. If this fails, it falls back on
>>>>>
>>>>> fchmod(4, 0100664)
>>>>>
>>>>>
>>>>> Now, on my low-level FUSE file system with xattr support, this results
>>>>> with the destination file having the wrong permission bits (600), but
>>>>> the correct ACL (664).
>>>>
>>>> IMHO, there should only be a (visible) set of permission bits.
>>>> The values returned by stat() and getfacl() have to be the
>>>> same.
>>>>
>>>>  From Posix draft PSSG/D17 (1997, never became a standard)
>>>>
>>>> 2.3.2.1
>>>>
>>>> The file permission bits of a file contain read, write and
>>>> execute/search permissions for the file owner class, file
>>>> group class and file other class.
>>>>
>>>> *These bits* are set at file creation by open(), creat(),
>>>> mkdir() and mkfifo(). They are changed by chmod(), and
>>>> if {POSIX_ACL] is defined, acl_set_file() and acl_set_fd().
>>>> These bits are read by stat(), and fstat().
>>>>
>>>
>>> Yes, that's pretty clear, thanks for the reference.
>>>
>>> But then the file system really has to be able to parse ACL extended
>>> attribute values, correct? So it would seem to me that the best place to
>>> do that would really be in FUSE itself, so that it's available to all
>>> FUSE file systems.
>>
>> Nikolaus,
>>
>> Can you have a try to do this in your own implementation (change the
>> mode internally), and see if FUSE can return the correct file mode? I
>> looked into FUSE code. It seems not revalidate the file mode after the
>> setxattr:
>>
>> http://lxr.linux.no/linux+v3.7.3/fs/fuse/dir.c#L1508
>>
>> This means FUSE might keep the old file mode untill it got expired.
>> IMO, FUSE should either call posix_acl_equiv_mode() and then
>> setattr():
>>
>> http://lxr.linux.no/linux+v3.7.2/fs/posix_acl.c#L149
>>
>> Or at least invalidate the inode attribute after the setxattr() call.
>
> Yes, fuse does not reivalidate the file mode after setxattr() calls (at
> least with Kernel 3.2 and fuse 2.9).
>
> I'll patch up some handler code in my file system based on
> posix_acl_equiv_mode (thanks for the link!) and an explicit
> fuse_lowlevel_notify_inval_inode call.


Unfortunately the format of the system.posix_acl_* attributes seems to
be an implementation detail of the kernel, so trying to parse and modify
it in a FUSE file system is probably a very bad idea.

It seems that the only workaround is to return an error from the
setxattr() and getxattr() when they're used to access
system.posix_acl_*. Not very nice either.


Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

Miklos Szeredi
On Wed, Jan 23, 2013 at 2:07 AM, Nikolaus Rath <[hidden email]> wrote:
>
>> I'll patch up some handler code in my file system based on
>> posix_acl_equiv_mode (thanks for the link!) and an explicit
>> fuse_lowlevel_notify_inval_inode call.
>
>
> Unfortunately the format of the system.posix_acl_* attributes seems to
> be an implementation detail of the kernel, so trying to parse and modify
> it in a FUSE file system is probably a very bad idea.

It's internal to kernel+libc, but the kernel-libc interface is a
pretty well defined and stable ABI.  So I don't think decoding xattrs
should be problematic in this regard.

We could add code to libfuse that does this, so we'd get an ACL
friendlier API, though.

Thanks,
Miklos

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

Nikolaus Rath
In reply to this post by Nikolaus Rath
Nikolaus Rath <[hidden email]> writes:

> Miklos Szeredi <[hidden email]> writes:
>> On Tue, Jan 22, 2013 at 3:23 AM, Nikolaus Rath <[hidden email]> wrote:
>>> Yes, fuse does not reivalidate the file mode after setxattr() calls (at
>>> least with Kernel 3.2 and fuse 2.9).
>>>
>>> I'll patch up some handler code in my file system based on
>>> posix_acl_equiv_mode (thanks for the link!) and an explicit
>>> fuse_lowlevel_notify_inval_inode call.
>>>
>>>
>>> I agree that FUSE should call posix_acl_equiv_mode(), followed by
>>> setattr() and (only if necessary) setxattr().
>>
>> FUSE kernel code doesn't support POSIX ACL's at all presently.
>>
>> Adding ACL support would make sense, and with that the reported bug
>> would be fixed.
>>
>> With ACL support turned off (as presently) then I think the current
>> behavior is fine: the kernel should just pass unmodified xattrs to
>> userspace.
>
> Hi Miklos,
>
> What do you mean with "ACL support turned off"? Presently a "cp -a" will
> call setfacl() on a FUSE file system, the call will be forwarded to the
> setxattr() handler, and to cp things will appear to work (with the
> exception that the permission bits will not get updated).

*ping*

Is setfacl/getfactl supposed to (automatically and always) return an
error on FUSE file systems?


Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

Miklos Szeredi
On Wed, Jan 30, 2013 at 2:53 AM, Nikolaus Rath <[hidden email]> wrote:

> Nikolaus Rath <[hidden email]> writes:
>> Miklos Szeredi <[hidden email]> writes:
>>> On Tue, Jan 22, 2013 at 3:23 AM, Nikolaus Rath <[hidden email]> wrote:
>>>> Yes, fuse does not reivalidate the file mode after setxattr() calls (at
>>>> least with Kernel 3.2 and fuse 2.9).
>>>>
>>>> I'll patch up some handler code in my file system based on
>>>> posix_acl_equiv_mode (thanks for the link!) and an explicit
>>>> fuse_lowlevel_notify_inval_inode call.
>>>>
>>>>
>>>> I agree that FUSE should call posix_acl_equiv_mode(), followed by
>>>> setattr() and (only if necessary) setxattr().
>>>
>>> FUSE kernel code doesn't support POSIX ACL's at all presently.
>>>
>>> Adding ACL support would make sense, and with that the reported bug
>>> would be fixed.
>>>
>>> With ACL support turned off (as presently) then I think the current
>>> behavior is fine: the kernel should just pass unmodified xattrs to
>>> userspace.
>>
>> Hi Miklos,
>>
>> What do you mean with "ACL support turned off"? Presently a "cp -a" will
>> call setfacl() on a FUSE file system, the call will be forwarded to the
>> setxattr() handler, and to cp things will appear to work (with the
>> exception that the permission bits will not get updated).
>
> *ping*
>
> Is setfacl/getfactl supposed to (automatically and always) return an
> error on FUSE file systems?

Well, I think yes.  Except it doesn't, so we can't just do that now
for fear of breaking something.

We fix such things by API versioning: old API/ABI just does what it
does now.  New API/ABI can negotiate ACL support and if it's off then
the *facl() will return an error.

Thanks,
Miklos

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

Jean-Pierre André
Hi

Miklos Szeredi wrote:
> On Wed, Jan 30, 2013 at 2:53 AM, Nikolaus Rath<[hidden email]>  wrote

[...]

>>> Hi Miklos,
>>>
>>> What do you mean with "ACL support turned off"? Presently a "cp -a" will
>>> call setfacl() on a FUSE file system, the call will be forwarded to the
>>> setxattr() handler, and to cp things will appear to work (with the
>>> exception that the permission bits will not get updated).
>>>        

Not necessarily : this can be handled in the file system,
and in ntfs-3g, ownership, permissions and Posix ACLs
use the same code (which translates them to NTFS ACLs)

>> *ping*
>>
>> Is setfacl/getfactl supposed to (automatically and always) return an
>> error on FUSE file systems?
>>      

Only for file systems which do not support Posix ACLs !

> Well, I think yes.  Except it doesn't, so we can't just do that now
> for fear of breaking something.
>    

You surely would.

Regards

Jean-Pierre

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

Miklos Szeredi
On Mon, Feb 4, 2013 at 1:40 PM, Jean-Pierre André
<[hidden email]> wrote:

> Hi
>
> Miklos Szeredi wrote:
>> On Wed, Jan 30, 2013 at 2:53 AM, Nikolaus Rath<[hidden email]>  wrote
>
> [...]
>
>>>> Hi Miklos,
>>>>
>>>> What do you mean with "ACL support turned off"? Presently a "cp -a" will
>>>> call setfacl() on a FUSE file system, the call will be forwarded to the
>>>> setxattr() handler, and to cp things will appear to work (with the
>>>> exception that the permission bits will not get updated).
>>>>
>
> Not necessarily : this can be handled in the file system,
> and in ntfs-3g, ownership, permissions and Posix ACLs
> use the same code (which translates them to NTFS ACLs)

Yes, the filesystem can handle it, but it's problematic due to issues
like the one that started this thread.

It would be better if the kernel part of fuse knew about ACLs and
would refuse to handle them if the filesystem did not actually say
that it can and wants to handle ACLs.


>>> Is setfacl/getfactl supposed to (automatically and always) return an
>>> error on FUSE file systems?
>>>
>
> Only for file systems which do not support Posix ACLs !
>
>> Well, I think yes.  Except it doesn't, so we can't just do that now
>> for fear of breaking something.
>>
>
> You surely would.

Yes, this is what I'm worried about.  So this *must* be implemented in
a backward compatible way.

Thanks,
Miklos

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

Sven Utcke-5
> >>>> What do you mean with "ACL support turned off"? Presently a "cp
> >>>> -a" will call setfacl() on a FUSE file system, the call will be
> >>>> forwarded to the setxattr() handler, and to cp things will
> >>>> appear to work (with the exception that the permission bits
> >>>> will not get updated).
> >
> > Not necessarily : this can be handled in the file system, and in
> > ntfs-3g, ownership, permissions and Posix ACLs use the same code
> > (which translates them to NTFS ACLs)

Same here.

> Yes, the filesystem can handle it, but it's problematic due to
> issues like the one that started this thread.

True.  But it "very nearly works" as is, which is a lot better than
not at all after that proposed change :-)

> It would be better if the kernel part of fuse knew about ACLs and
> would refuse to handle them if the filesystem did not actually say
> that it can and wants to handle ACLs.

Well, I for my part have always figured that implementing an handler
for extended attributes meant just that.

Than again, I certainly did wish for some ACL-support from FUSE, and
preferably even separate functions for ACLs and EAs.

> >>> Is setfacl/getfactl supposed to (automatically and always) return an
> >>> error on FUSE file systems?

> >> Well, I think yes.  Except it doesn't, so we can't just do that now
> >> for fear of breaking something.
> >
> > You surely would.

Seconded.

> Yes, this is what I'm worried about.  So this *must* be implemented
> in a backward compatible way.

Yes, please.

Sven
--
    _  ___  ___  ___                              The dCache File System
 __| |/ __|| __|/ __|              An archive file-system for PB of data
/ _` | (__ | _| \__ \                    http://www.desy.de/~utcke/Data/
\__,_|\___||_|  |___/                            http://www.dr-utcke.de/

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

Nikolaus Rath
In reply to this post by Jean-Pierre André
Jean-Pierre André <[hidden email]> writes:

> Hi
>
> Miklos Szeredi wrote:
>> On Wed, Jan 30, 2013 at 2:53 AM, Nikolaus Rath<[hidden email]>  wrote
>
> [...]
>
>>>> Hi Miklos,
>>>>
>>>> What do you mean with "ACL support turned off"? Presently a "cp -a" will
>>>> call setfacl() on a FUSE file system, the call will be forwarded to the
>>>> setxattr() handler, and to cp things will appear to work (with the
>>>> exception that the permission bits will not get updated).
>>>>        
>
> Not necessarily : this can be handled in the file system,
> and in ntfs-3g, ownership, permissions and Posix ACLs
> use the same code (which translates them to NTFS ACLs)

How do you parse and generate the value of the ACL extended attributes?
I'm very interested in copying that code :-).


Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

Nikolaus Rath
In reply to this post by Sven Utcke-5
Sven Utcke <[hidden email]> writes:

>> >>>> What do you mean with "ACL support turned off"? Presently a "cp
>> >>>> -a" will call setfacl() on a FUSE file system, the call will be
>> >>>> forwarded to the setxattr() handler, and to cp things will
>> >>>> appear to work (with the exception that the permission bits
>> >>>> will not get updated).
>> >
>> > Not necessarily : this can be handled in the file system, and in
>> > ntfs-3g, ownership, permissions and Posix ACLs use the same code
>> > (which translates them to NTFS ACLs)
>
> Same here.

Same request, could you point me to the code? I'd like to upgrade my
implementation from "not working at all" to "very nearly working" :-).

Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

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

Nikolaus Rath wrote:

> Jean-Pierre André<[hidden email]>  writes:
>    
>> Hi
>>
>> Miklos Szeredi wrote:
>>      
>>> On Wed, Jan 30, 2013 at 2:53 AM, Nikolaus Rath<[hidden email]>   wrote
>>>        
>> [...]
>>
>>      
>>>>> Hi Miklos,
>>>>>
>>>>> What do you mean with "ACL support turned off"? Presently a "cp -a" will
>>>>> call setfacl() on a FUSE file system, the call will be forwarded to the
>>>>> setxattr() handler, and to cp things will appear to work (with the
>>>>> exception that the permission bits will not get updated).
>>>>>
>>>>>            
>> Not necessarily : this can be handled in the file system,
>> and in ntfs-3g, ownership, permissions and Posix ACLs
>> use the same code (which translates them to NTFS ACLs)
>>      
> How do you parse and generate the value of the ACL extended attributes?
> I'm very interested in copying that code :-).
>    

Most of the code is in

http://ntfs-3g.git.sourceforge.net/git/gitweb.cgi?p=ntfs-3g/ntfs-3g;a=blob_plain;f=libntfs-3g/security.c;hb=HEAD

The functions which may be of some usefulness to
you have a name ending in "_posix"

and most of the xattr-to-acl interfacing (with endianness
translations so that the rest of the code is cpu-endian) is in

http://ntfs-3g.git.sourceforge.net/git/gitweb.cgi?p=ntfs-3g/ntfs-3g;a=blob_plain;f=libntfs-3g/xattrs.c;hb=HEAD

Regards

Jean-Pierre


------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Should ACLs updates affect permission bits?

Sven Utcke-5
In reply to this post by Nikolaus Rath
Hello Nikolaus,

> Same request, could you point me to the code? I'd like to upgrade my
> implementation from "not working at all" to "very nearly working"
> :-).

I'll have to check the licensing on the code (some is free, some not),
but I guess that's not much of a problem.
On the other hand it might not be much help either, as all the ACL
parsing was handcoded (and we have now learned that system functions
exist for this job), uses a mySQL database for attribute storage, and
possibly did not have to deal with some problems as the files
themselves are immutable (i.e. only the attributes can change).

That said, it passed nearly all tests of some POSIX testsuit related
to ACLs (and all others).  Forgot which ones failed, but presumably
something to do with timeouts of caches...

And of course the usual disclaimer about the code being a mess applies
:-)

Just ping me again should I forget to get back to you within this
week.

Sven
--
    _  ___  ___  ___                              The dCache File System
 __| |/ __|| __|/ __|              An archive file-system for PB of data
/ _` | (__ | _| \__ \                    http://www.desy.de/~utcke/Data/
\__,_|\___||_|  |___/                            http://www.dr-utcke.de/

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

What errno to return for ACL access (was: Should ACLs updates affect permission bits?)

Nikolaus Rath
In reply to this post by Nikolaus Rath
Nikolaus Rath <[hidden email]> writes:
[ FUSE does not keep ACLs and permission bits in sync ]
> Unfortunately the format of the system.posix_acl_* attributes seems to
> be an implementation detail of the kernel, so trying to parse and modify
> it in a FUSE file system is probably a very bad idea.
>
> It seems that the only workaround is to return an error from the
> setxattr() and getxattr() when they're used to access
> system.posix_acl_*. Not very nice either.

Apparently this is more tricky than I thought. If I return ENOSYS from
getxattr/setxattr when the attribute name matches system.posix_acl_*,
FUSE believes the handler is not implemented at all and any subsequent
getxattr/setxattr no longer get passed to the file system, even if they
don't relate to ACLs at all.

If I return EINVAL instead, the handler gets called every time, but
applications like rsync flood the user with error messages (while for
ENOSYS they correctly deduce that the fs simply has no ACL support).

Does anyone have a recommendation what errno I can safely return here?

I know that in the end there can always be the odd client application
for which it fails, but I'd like to make the errno at least as
compatible as possible.


Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
12