Re: [fuse-devel] FUSE + Linux filesystem capabilities

[Mike M. <jm...@ca...>]

On May 11, 2009, at 10:42 AM, John Muir wrote:

> On 11-May-09, at 11:30 AM, Mike Morrison wrote:
>> On May 11, 2009, at 10:21 AM, Miklos Szeredi wrote:
>>> On Mon, 11 May 2009, Mike Morrison wrote:
>>>> Just for grins this morning, I've tried returning ENODATA, ENOTSUP/
>>>> EOPNOTSUP, ENOATTR and 0, none of which prevent the continued  
>>>> attempts
>>>> to get the caps.
>>>
>>> Try ENOSYS.
>>
>> Yes!  That works.  If returned, I see no more requests for that  
>> extended attributes, not just on the original file, but on any  
>> file.  Thank you!
>>
>> If it's not too difficult to explain, what is the magic there?
>
> The FUSE kernel module keys on ENOSYS from the (user space) file- 
> system to disable the extended attribute function calls. For  
> example, see fuse_getxattr() in <kernel>/fs/fuse/dir.c. There is  
> only an issue is if you actually intended to use extended attributes  
> (like me). I'll be seeking another option. I can't believe that this  
> needs to precede *every* write operation.

Ah, I guess I'm in the same boat, as we also need general xattr  
support.  Dang.

FWIW, I dug through the bug report and found this, further details of  
which I'm sorry to say I don't have, but perhaps will light a bulb  
over someone else's head:

"*I believe* that this is occurring because in mm/ 
filemap.c:__generic_file_aio_write_nolock() there's a call to  
file_remove_suid() which down the call graph a ways tries to remove  
the capabilities, but does so by checking to see if the capabilities  
xattr is there before it attempts to delete it."

--jmike