On Tue, Apr 11, 2023 at 06:13:15AM -0400, Jeff Layton wrote: > 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. Ah, good. > > 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. Yeah, that's what I thought and that would potentially be an attack on IMA which is why I asked. Thanks! Christian
