On Tue, 23 Apr 2024 at 23:38, The 8472 <kernel@xxxxxxxxxxxxxxxxxx> wrote: > In some places we do rely on error codes having exactly the documented meaning > and no other. E.g. fcntl(..., F_GETFD) failing with EBADF is treated as fatal, > other codes are not. > Or openat(..., O_NOFOLLOW | O_DIRECTORY) returning ENOTDIR is trusted to mean > that the file is in fact not a directory and can be unlinked instead of rmdir'd There are lot of assumptions from applications. Fuse won't and can't check them all. This applies to error codes as well. > Current Rust versions unwind if closedir() is not successful since > directories aren't writable and aren't expected to have writeback > errors. That's what lead to this thread. Is that bad? I mean can that lead to a security breach? If not, then it's not interesting, lets just fix the bad filesystem. > If that had returned an EIO that would have been annoying but > would clearly point at unreliable storage. If it returns > EBADF that is more concerning because it could be a double-close or > something similar within the process clobbering FDs. So the worst thing that can happen is that a bad fuse filesystem is able to confuse the user of an application, believing the application is at fault when in fact it's the filesystem that's acting up? > So if linux implements its fuse client in a way that propagates arbitrary > error codes to syscalls for which the linux-specific documentation says that only > a certain set of error codes with specific meanings would be returned then > either the documentation is wrong or those errors should be mangled before > they bubble up to the syscall. Man pages do not say that the error list is exhaustive. Other error codes are almost always possible even without fuse. Thanks, Miklos
