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

[Jeff Layton]

On Tue, 2023-04-11 at 11:49 +0200, Christian Brauner wrote:
> 
> > 
> > > Afaict, filesystems that persist i_version to disk automatically raise
> > > SB_I_VERSION. I would guess that it be considered a bug if a filesystem
> > > would persist i_version to disk and not raise SB_I_VERSION. If so IMA
> > > should probably be made to check for IS_I_VERSION() and it will probably
> > > get that by switching to vfs_getattr_nosec().
> > 
> > Not quite. SB_I_VERSION tells the vfs that the filesystem wants the
> > kernel to manage the increment of the i_version for it. The filesystem
> > is still responsible for persisting that value to disk (if appropriate).
> 
> Yes, sure it's the filesystems responsibility to persist it to disk or
> not. What I tried to ask was that when a filesystem does persist
> i_version to disk then would it be legal to mount it without
> SB_I_VERSION (because ext2/ext3 did use to have that mount option)? If
> it would then the filesystem would probably need to take care to leave
> the i_version field in struct inode uninitialized to avoid confusion or
> would that just work? (Mere curiosity, don't feel obligated to go into
> detail here. I don't want to hog your time.)
> 

In modern kernels, not setting SB_I_VERSION would mainly have the effect
of stopping increments of i_version field on write. It would also mean
that the STATX_CHANGE_COOKIE is not automatically reported via getattr.

You probably wouldn't want to mount the fs without SB_I_VERSION set. The
missing increments could trick an observer into believing that nothing
had changed in the file across mounts when it actually had.
-- 
Jeff Layton <jlayton@xxxxxxxxxx>