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]

Date:   Tue, 17 Jan 2023 19:41:46 -0800
From:   Jonathan Katz <jkatz@...mlabs.org>
To:     Christian Kohlschütter 
        <christian@...lschutter.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Miklos Szeredi <miklos@...redi.hu>,
        overlayfs <linux-unionfs@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] [REGRESSION] ovl: Handle ENOSYS when fileattr support is
 missing in lower/upper fs


On 7/18/22 13:33, Christian Kohlschütter wrote:
>> Am 18.07.2022 um 22:12 schrieb Linus Torvalds <torvalds@...ux-foundation.org>:
>>
>> On Mon, Jul 18, 2022 at 12:28 PM Miklos Szeredi <miklos@...redi.hu> wrote:
>>> So this is a bug in the kernel part of fuse, that doesn't catch and
>>> convert ENOSYS in case of the ioctl request.
>> Ahh, even better. No need to worry about external issues.
>>
>>             Linus
> My concern was fixing it in fuse instead of ovl would leave non-fuse filesystems affected (even though I don't have proof that such filesystems exist).
>
> I'm glad you are OK with Miklos' change; the outcome of this discussion certainly adds some nuance to the famous "don't break userspace" / error code thread from 2012.
>
> Best,
> Christian
>
I believe that I am still having issues occur within Ubuntu 22.10 with 
the 5.19 version of the kernel that might be associated with this 
discussion.  I apologize up front for any faux pas I make in writing 
this email.

An example error from our syslog:

kernel: [2702258.538549] overlayfs: failed to retrieve lower fileattr 
(8020 MeOHH2O 
RecoverySample2-20221219-A-JJL-WebinarHilic10C-TOF-TT54-Neg-1722.d/analysis.tsf, 
err=-38)

The only other related log notification I get occurs when I do the 
overlay mount:

kernel: [2702222.266404] overlayfs: null uuid detected in lower fs '/', 
falling back to xino=off,index=off,nfs_export=off.


In the following description, the error is occurring on FileServer2

Our configuration is as follows:

FileServer1 "/data" --- NFS(ro)----->  FileServer2

On FileServer2 I wish to export that /data directory via Samba so it 
appears as RW by a specific user.  I accomplish this with bindfs 
followed by overlayfs:

# bindfs -u 1001 -g 1001 /data /overlay/lowers/data-1001
# mount -t overlay overlay -o lowerdir= /overlay/lowers/data-1001,\
upperdir=/overlay/uppers/upper-1001,\
workdir=/overlay/work/work-1001,\
/overlay/mountpoints/data-1001

Then I serve this out via Samba:

FileServer2 "/overlay/mountpoints/data-1001" ------ ( SAMBA/CIFS) --->  
Win-Client


I repeat this bind/mount for several users - each with their own 
"writable" copy of the data.  This mostly works very well... but there 
are some software packages on the win client that fail mysteriously and 
my FileSystem2 log shows "err=-38" messages for various files at the 
same time.

I am guessing there is some relation between the lack of uuid (because 
it is NFS or a bindfs?) and the failure to retrieve the low fileattr, 
but, I am humbly out of my depth here.

-Jonathan