linux-kernel - Re: [RFC PATCH 0/1] ovl: brtfs' temp_fsid doesn't work with ovl index=on

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: <6982bc0a-bb12-458a-bb8c-890c363ba807@suse.com>
Date: Wed, 15 Oct 2025 07:38:33 +1030
From: Qu Wenruo <wqu@...e.com>
To: dsterba@...e.cz, André Almeida <andrealmeid@...lia.com>
Cc: linux-kernel@...r.kernel.org, linux-btrfs@...r.kernel.org,
 linux-unionfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 kernel-dev@...lia.com, Miklos Szeredi <miklos@...redi.hu>,
 Amir Goldstein <amir73il@...il.com>, Chris Mason <clm@...com>,
 David Sterba <dsterba@...e.com>, Anand Jain <anand.jain@...cle.com>,
 "Guilherme G . Piccoli" <gpiccoli@...lia.com>
Subject: Re: [RFC PATCH 0/1] ovl: brtfs' temp_fsid doesn't work with ovl
 index=on

在 2025/10/15 04:54, David Sterba 写道:
> On Mon, Oct 13, 2025 at 10:57:06PM -0300, André Almeida wrote:
>> Hi everyone,
>>
>> When using overlayfs with the mount option index=on, the first time a directory is
>> used as upper dir, overlayfs stores in a xattr "overlay.origin" the UUID of the
>> filesystem being used in the layers. If the upper dir is reused, overlayfs
>> refuses to mount for a different filesystem, by comparing the UUID with what's
>> stored at overlay.origin, and it fails with "failed to verify upper root origin"
>> on dmesg. Remounting with the very same fs is supported and works fine.
>>
>> However, btrfs mounts may have volatiles UUIDs. When mounting the exact same
>> disk image with btrfs, a random UUID is assigned for the following disks each
>> time they are mounted, stored at temp_fsid and used across the kernel as the
>> disk UUID. `btrfs filesystem show` presents that. Calling statfs() however shows
>> the original (and duplicated) UUID for all disks.
>>
>> This feature doesn't work well with overlayfs with index=on, as when the image
>> is mounted a second time, will get a different UUID and ovl will refuse to
>> mount, breaking the user expectation that using the same image should work. A
>> small script can be find in the end of this cover letter that illustrates this.
>>
>> >From this, I can think of some options:
>>
>> - Use statfs() internally to always get the fsid, that is persistent. The patch
>> here illustrates that approach, but doesn't fully implement it.
>> - Create a new sb op, called get_uuid() so the filesystem returns what's
>> appropriated.
>> - Have a workaround in ovl for btrfs.
>> - Document this as unsupported, and userland needs to erase overlay.origin each
>> time it wants to remount.
>> - If ovl detects that temp_fsid and index are being used at the same time,
>> refuses to mount.
>>
>> I'm not sure which one would be better here, so I would like to hear some ideas
>> on this.
> 
> I haven't looked deeper if there's a workable solution, but the feature
> combination should be refused. I don't think this will affect many
> users.
> 

I believe the root problem is that we're not fully implementing the 
proper handling just like other single-device fses.

We do not use on-disk flags which means at least one fsid is registered 
into btrfs, thus we have to use different temp-fsid.

If fully single-device feature flag is properly implemented, we should 
be able to return the same uuid without extra hacks thus solve the problem.

Thanks,
Qu