Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <b137033f3cd971b0cfc71045cab63440dfe9c7f8.camel@kernel.org>
Subject: Re: [PATCH] overlayfs: Trigger file re-evaluation by IMA / EVM
 after writes
From:   Jeff Layton <jlayton@kernel.org>
To:     Christian Brauner <brauner@kernel.org>
Cc:     Amir Goldstein <amir73il@gmail.com>,
        Stefan Berger <stefanb@linux.ibm.com>,
        Paul Moore <paul@paul-moore.com>, zohar@linux.ibm.com,
        linux-integrity@vger.kernel.org, miklos@szeredi.hu,
        linux-kernel@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org
Date:   Tue, 11 Apr 2023 06:13:15 -0400
In-Reply-To: <20230411-holzbalken-stuben-6cea8b722a1b@brauner>
References: <20230407-trasse-umgearbeitet-d580452b7a9b@brauner>
         <90a25725b4b3c96e84faefdb827b261901022606.camel@kernel.org>
         <20230409-genick-pelikan-a1c534c2a3c1@brauner>
         <b2591695afc11a8924a56865c5cd2d59e125413c.camel@kernel.org>
         <20230411-umgewandelt-gastgewerbe-870e4170781c@brauner>
         <8f5cc243398d5bae731a26e674bdeff465da3968.camel@kernel.org>
         <20230411-holzbalken-stuben-6cea8b722a1b@brauner>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

On Tue, 2023-04-11 at 11:49 +0200, Christian Brauner wrote:
>=20
> >=20
> > > Afaict, filesystems that persist i_version to disk automatically rais=
e
> > > SB_I_VERSION. I would guess that it be considered a bug if a filesyst=
em
> > > 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 proba=
bly
> > > get that by switching to vfs_getattr_nosec().
> >=20
> > 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)=
.
>=20
> 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.)
>=20

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.
--=20
Jeff Layton <jlayton@kernel.org>