On Thu, Sep 11, 2025 at 03:31:21PM -0700, Darrick J. Wong wrote: > > Is there a risk that some garbage written to s_reserved (and not caught > by either the kernel or e2fsck) will now appear as a "legitimate" resuid > value? The superblock is checksumed, so the risk would be that some impleentation modifies the superblock and updates s_reserved for some reason. But they could do that to any superblock field, or to the low 16 bits of s_resuid/s_resgid today, and that's something that neither the kernel or e2fsck could check. The mke2fs program zeroes all of the unused/reserved portions of the superblock, so the risk is some random non-Linux implementation (e.g., GNU Hurd or BSD) had hijacked some reserved field without coordinating with upstream ext4. I thought about using some kind of compat feature flag, but it probably wouldn't help since the other implementation would likely not bother to use their own feature flag since that would prevent the file system to be mounted with Linux. Currently, someone tried to run "tune2fs -u 146878 /tmp/foo.img" we'll silently drop the high 16 bits: % tune2fs -u 146878 /tmp/foo.img tune2fs 1.47.3-rc2 (12-Jun-2025) Setting reserved blocks uid to 146878 % dumpe2fs -h /tmp/foo.img | grep uid dumpe2fs 1.47.3-rc2 (12-Jun-2025) Reserved blocks uid: 15806 (user tytso) And if we have implementations that support 32-bit reserved uid's/gid's, and the file system is mounted on an older kernel, it will simply use a different reserved uid (e.g., 15806 instead of 146878). But we're kind of confused today, and in practice most of the time people will be using low reserved uid's/gid's (e.g., 1 for daemon, etc.). - Ted
