Re: EBADF returned from close() by FUSE

[Antonio SJ Musumeci <trapexit@spawn.link>]

On 4/23/24 07:46, Miklos Szeredi wrote:
> On Sat, 20 Apr 2024 at 01:04, The 8472 <kernel@infinite-source.de> wrote:
>
>> If it is the official position that the whims of FUSE servers have
>> primacy over current kernel API guarantees then please update
>> the documentation of all affected syscalls and relax those
>> guarantees, similar to the note on the write(2) manpage.
> Which note are you referring to?
>
> I can see some merit to both sides.
>
> If it's an issue that can be fixed in the fuse server ("Doctor, it
> hurts when I do this." "Then don't do that!”) adding complexity to the
> fuse client is not warranted.
>
> Obviously most fuse servers don't want to actively confuse caller, but
> if such behavior can be used to exploit a weakness in an application,
> then it becomes more than just a correctness issue.  If you came up
> with such a scenario, then this would turn into a serious bug.
>
> Thanks,
> Miklos

 From the write(2) manpage (at least on Ubuntu):

"Other errors may occur, depending on the object connected to fd."

My argument has been that this note is defacto true generally.

The specifics of this thread stem from close() returning EBADF to the 
client app while talking to a FUSE server after the open() succeeded 
and, from the point of view of the client app, returned a valid file 
descriptor. Sounds like a bug in the FUSE server rather than something 
FUSE itself needs to worry about. Besides removing some classes of usage 
of FUSE it would be rather complicated, if not impossible, to assume the 
meaning of returned errors from the server and translate them into 
"approved" values for the client. It will mask server bugs and/or 
confuse server authors at best IMO. Error handling in FUSE is already a 
bit difficult to manage.

This is not unlike a recent complaint that when link() is not 
implemented libfuse returns ENOSYS rather than EPERM. As I pointed out 
in that situation EPERM is not universally defined as meaning "not 
implemented by filesystem" like used in Linux. Doesn't mean it isn't 
used (I didn't check) but it isn't defined as such in docs.