Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 26 Jan 2022 10:40:42 +0100
From:   Christian Brauner <brauner@kernel.org>
To:     Stefan Berger <stefanb@linux.vnet.ibm.com>
Cc:     linux-integrity@vger.kernel.org, zohar@linux.ibm.com,
        serge@hallyn.com, christian.brauner@ubuntu.com,
        containers@lists.linux.dev, dmitry.kasatkin@gmail.com,
        ebiederm@xmission.com, krzysztof.struczynski@huawei.com,
        roberto.sassu@huawei.com, mpeters@redhat.com, lhinds@redhat.com,
        lsturman@redhat.com, puiterwi@redhat.com, jejb@linux.ibm.com,
        jamjoom@us.ibm.com, linux-kernel@vger.kernel.org,
        paul@paul-moore.com, rgb@redhat.com,
        linux-security-module@vger.kernel.org, jmorris@namei.org,
        Stefan Berger <stefanb@linux.ibm.com>
Subject: Re: [PATCH v9 10/23] ima: Move IMA securityfs files into
 ima_namespace or onto stack
Message-ID: <20220126094042.l6jqu5swwsyhlt7v@wittgenstein>
References: <20220125224645.79319-1-stefanb@linux.vnet.ibm.com>
 <20220125224645.79319-11-stefanb@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20220125224645.79319-11-stefanb@linux.vnet.ibm.com>
Precedence: bulk

On Tue, Jan 25, 2022 at 05:46:32PM -0500, Stefan Berger wrote:
> From: Stefan Berger <stefanb@linux.ibm.com>
> 
> Only the securityfs IMA policy file is ever removed based on Kconfig
> options. For this reason, move the IMA securityfs policy file variable
> 'ima_policy' into the ima_namespace.
> 
> Move the other IMA securityfs files onto the stack since they are not
> needed outside the function where they are created in. Also, their cleanup
> is automatically handled by the filesystem upon umount of a virtualized
> securityfs instance, so they don't need to be explicitly freed.

I'd reverse the explantion in the commit and mention the securityfs
change that makes this move possible which is patch 3 in this version of
the series ("securityfs: rework dentry creation"); something like:

	Earlier we simplified how dentry creation and deletion is manged in
	securityfs. This allows us to move IMA securityfs files from global
	variables directly into ima_fs_ns_init() itself. We can now rely on
	those dentries to be cleaned up when the securityfs instance is cleaned
	when the last reference to it is dropped.
	
	Things are slightly different for the initial ima namespace. In contrast
	to non-initial ima namespaces it has pinning logic binding the lifetime
	of the securityfs superblock to created dentries. We need to keep this
	behavior to not regress userspace. Since ima never removes most of the
	securityfs files the initial securityfs instance stays pinned. This also
	means even for the initial ima namespace we don't need to keep
	references to these dentries anywhere.
	
	The ima_policy file is the exception since ima can end up removing it if
	a non-default policy is written at some point.

Last sentence should be checked for sensibility by ima folks.

> 
> In the failure cleanup path clean up the ima_policy dentry before
> cleaning up the directories.
> 
> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
> 
> ---

Moving into imans looks good,
Acked-by: Christian Brauner <brauner@kernel.org>