EBADF returned from close() by FUSE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux