Re: uuid ioctl - was: Re: [PATCH] overlayfs: Trigger file re-evaluation by IMA / EVM after writes

["Theodore Ts'o" <tytso@mit.edu>]

On Mon, Jun 05, 2023 at 01:37:40PM +0200, Christian Brauner wrote:
> Using a zero/special UUID would have made this usable for most
> filesystems which allows userspace to more easily detect this. Using a
> filesystem feature bit makes this a lot more fragmented between
> filesystems.

Not all file systems have feature bits.  So I'd suggest that how this
should be a file system specific implementation detail.  If with a
newer kernel, a file systems sets the UUID to a random value if it is
all zeros when it is mounted should be relatively simple.

However, there are some questions this brings up.  What should the
semantics be if a file system creates a file system-level snapshot ---
should the UUID be refreshed?  What if it is a block-level file system
snapshot using LVM --- should the UUID be refreshed in that case?

As I've been trying to point out, exactly what the semantics of a file
system level UUID has never been well defined, and it's not clear what
various subsystems are trying to *do* with the UUID.  And given that
what can happen with mount name spaces, bind mounts, etc., we should
ask whether the assumptions they are making with respect to UUID is in
fact something we should be encouraging.

> But allowing to refuse being mounted on older kernels when the feature
> bit is set and unknown can be quite useful. So this is also fine by me.

This pretty much guarantees people won't use the feature for a while.
People complain when a file system cann't be mounted.  Using a feature
bit is also very likely to mean that you won't be able to run an older
fsck on that file system --- for what users would complain would be no
good reason.  And arguably, they would be right to complain.

						- Ted