linux-kernel - Re: [PATCH] [REGRESSION] ovl: Handle ENOSYS when fileattr support is missing in lower/upper fs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <A31096BA-C128-4D0B-B27D-C34560844ED0@kohlschutter.com>
Date:   Mon, 18 Jul 2022 15:03:52 +0200
From:   Christian Kohlschütter 
        <christian@...lschutter.com>
To:     Miklos Szeredi <miklos@...redi.hu>, torvalds@...ux-foundation.org
Cc:     overlayfs <linux-unionfs@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] [REGRESSION] ovl: Handle ENOSYS when fileattr support is
 missing in lower/upper fs

Am 18.07.2022 um 14:21 schrieb Miklos Szeredi <miklos@...redi.hu>:
> 
> On Mon, 18 Jul 2022 at 12:56, Christian Kohlschütter
> <christian@...lschutter.com> wrote:
> 
>> However, users of fuse that have no business with overlayfs suddenly see their ioctl return ENOTTY instead of ENOSYS.
> 
> And returning ENOTTY is the correct behavior.  See this comment in
> <asm-generic/errrno.h>:
> 
> /*
> * This error code is special: arch syscall entry code will return
> * -ENOSYS if users try to call a syscall that doesn't exist.  To keep
> * failures of syscalls that really do exist distinguishable from
> * failures due to attempts to use a nonexistent syscall, syscall
> * implementations should refrain from returning -ENOSYS.
> */
> #define ENOSYS 38 /* Invalid system call number */
> 
> Thanks,
> Miklos

That ship is sailed since ENOSYS was returned to user-space for the first time.

It reminds me a bit of Linus' "we do not break userspace" email from 2012 [1, 2], where Linus wrote:
> Applications *do* care about error return values. There's no way in
> hell you can willy-nilly just change them. And if you do change them,
> and applications break, there is no way in hell you can then blame the
> application.

(Adding Linus for clarification whether his statement is still true in 2022, and marking subject with regression tag for visibility.)

As far as I, a fuse user, understand, fuse uses ENOSYS as a specific marker to indicate permanent failure:

From libfuse https://libfuse.github.io/doxygen/structfuse__lowlevel__ops.html:
> If this request is answered with an error code of ENOSYS, this is treated as a permanent failure with error code EOPNOTSUPP, i.e. all future getxattr() requests will fail with EOPNOTSUPP without being send to the filesystem process.

(also see  https://man.openbsd.org/fuse_new.3)


Again, in summary:
1. I believe the fix should be in ovl, because ovl caused the regression.
2. Fixing in fuse would not be sufficient because other lower filesystems that also return ENOSYS remain affected (a cursory search indicates ecryptfs also returns ENOSYS).
3. Fixing in fuse would break user-space. We do not break userspace.

Cheers,
Christian



[1] https://lkml.org/lkml/2012/12/23/75
[2] https://lkml.org/lkml/2012/12/23/99