From: The 8472 <kernel@infinite-source.de>
To: linux-fsdevel@vger.kernel.org
Subject: EBADF returned from close() by FUSE
Date: Fri, 19 Apr 2024 00:10:46 +0200 [thread overview]
Message-ID: <1b946a20-5e8a-497e-96ef-f7b1e037edcb@infinite-source.de> (raw)
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
next reply other threads:[~2024-04-18 22:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-18 22:10 The 8472 [this message]
2024-04-19 3:30 ` EBADF returned from close() by FUSE Antonio SJ Musumeci
2024-04-19 6:55 ` The 8472
[not found] ` <8c7552b1-f371-4a75-98cc-f2c89816becb@spawn.link>
2024-04-19 18:18 ` The 8472
2024-04-19 20:07 ` Antonio SJ Musumeci
2024-04-19 20:45 ` The 8472
2024-04-19 21:29 ` Antonio SJ Musumeci
2024-04-19 22:04 ` The 8472
2024-04-19 22:47 ` Antonio SJ Musumeci
2024-04-19 23:04 ` The 8472
2024-04-23 12:46 ` Miklos Szeredi
2024-04-23 13:24 ` Antonio SJ Musumeci
2024-04-23 13:38 ` Miklos Szeredi
[not found] ` <692a9f0b-9c2b-4850-b8bc-48f09fe41762@infinite-source.de>
2024-04-23 21:38 ` The 8472
2024-04-26 8:52 ` Miklos Szeredi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1b946a20-5e8a-497e-96ef-f7b1e037edcb@infinite-source.de \
--to=kernel@infinite-source.de \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).