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-next>] [day] [month] [year] [list]
Message-ID: <20251014015707.129013-1-andrealmeid@igalia.com>
Date: Mon, 13 Oct 2025 22:57:06 -0300
From: André Almeida <andrealmeid@...lia.com>
To: linux-kernel@...r.kernel.org,
	linux-btrfs@...r.kernel.org,
	linux-unionfs@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Cc: 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>,
	André Almeida <andrealmeid@...lia.com>
Subject: [RFC PATCH 0/1] ovl: brtfs' temp_fsid doesn't work with ovl index=on

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.

Thanks!
	André

---

To reproduce:

mkdir -p dir1 dir2

fallocate -l 300m ./disk1.img
mkfs.btrfs -q -f ./disk1.img

# cloning the disks
cp disk1.img disk2.img
sudo mount -o loop ./disk1.img dir1
sudo mount -o loop ./disk2.img dir2

mkdir -p dir2/lower aux/upper aux/work

# this works
sudo mount -t overlay -o lowerdir=dir2/lower,upperdir=aux/upper,workdir=aux/work,userxattr none dir2/lower

sudo umount dir2/lower
sudo umount dir2

sudo mount -o loop ./disk2.img dir2

# this doesn't works
sudo mount -t overlay -o lowerdir=dir2/lower,upperdir=aux/upper,workdir=aux/work,userxattr none dir2/lower

André Almeida (1):
  ovl: Use fsid as unique identifier for trusted origin

 fs/overlayfs/copy_up.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

-- 
2.51.0


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ