Re: EBADF returned from close() by FUSE

[The 8472 <kernel@infinite-source.de>]

On 19-04-2024 05:30, Antonio SJ Musumeci wrote:
> On 4/18/24 17:10, The 8472 wrote:
>> Hello, first time mailing the kernel mailing lists here, I hope got the right one.
>>
>> I'm investigating a bug report against the Rust standard library about error handling
>> when closing file descriptors[0].
>> Testing shows that a FUSE flush request can be answered with a EBADF error
>> and this is surfaced to the close() call.
>>
>> I am asking if it is intended behavior that filesystems can pass arbitrary error codes.
>>
>> Specifically a EBADF returned from close() and other syscalls that only use that code
>> to indicate that it's not an open FD number is concerning since attempting to use
>> an incorrect FD number would normally indicate a double-drop or some other part
>> of the program trampling over file descriptors it is not supposed to touch.
>>
>> But if FUSE or other filesystems can pass arbitrary error codes into syscall results
>> then it becomes impossible to distinguish fatally broken invariants (file descriptor ownership
>> within a program) from merely questionable fileystem behavior.
>> Since file descriptors are densely allocated (no equivalent to ASLR or guard pages)
>> there are very little guard rails against accidental ownership violations.
>>
>>
>> - The 8472
>>
>> [0] https://github.com/rust-lang/rust/issues/124105
> I can't see how the kernel could meaningfully know of or limit errors
> coming from the FUSE server without compromising the nature of the
> technology. So in that sense... yes, it is intentional.

File descriptor numbers are not a FUSE-managed resource, so I was hoping
it would reserve error codes that are documented to signal incorrect
access to that resource and convert external errors to another code (e.g. EIO).
This would then signal that the file descriptor itself was valid but the underlying
resource encountered an error while performing the operation.