Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
Message-ID: <893bc5837fea4395bfb19e35097810ec7e425917.camel@huaweicloud.com>
Subject: Re: [PATCH v3 02/25] ima: Align ima_post_path_mknod() definition
 with LSM infrastructure
From:   Roberto Sassu <roberto.sassu@huaweicloud.com>
To:     Mimi Zohar <zohar@linux.ibm.com>, viro@zeniv.linux.org.uk,
        brauner@kernel.org, chuck.lever@oracle.com, jlayton@kernel.org,
        neilb@suse.de, kolga@netapp.com, Dai.Ngo@oracle.com,
        tom@talpey.com, dmitry.kasatkin@gmail.com, paul@paul-moore.com,
        jmorris@namei.org, serge@hallyn.com, dhowells@redhat.com,
        jarkko@kernel.org, stephen.smalley.work@gmail.com,
        eparis@parisplace.org, casey@schaufler-ca.com
Cc:     linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-nfs@vger.kernel.org, linux-integrity@vger.kernel.org,
        linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
        selinux@vger.kernel.org, Roberto Sassu <roberto.sassu@huawei.com>
Date:   Fri, 13 Oct 2023 09:38:16 +0200
In-Reply-To: <102b06b30518ac6595022e079de92717c92f3b8e.camel@linux.ibm.com>
References: <20230904133415.1799503-1-roberto.sassu@huaweicloud.com>
         <20230904133415.1799503-3-roberto.sassu@huaweicloud.com>
         <a733fe780a3197150067ad35ed280bf85e11fa97.camel@linux.ibm.com>
         <b51baf7741de1fdee8b36a87bd2dde71184d47a8.camel@huaweicloud.com>
         <8646e30b0074a2932076b5a0a792b14be034de98.camel@linux.ibm.com>
         <16c8c95f2e63ab9a2fba8cba919bf129d0541b61.camel@huaweicloud.com>
         <c16551704db68c6e0ba89c729c892e9401f05dfc.camel@linux.ibm.com>
         <2336abd6ae195eda221d54e3c2349a4760afaff2.camel@huaweicloud.com>
         <84cfe4d93cb5b02591f4bd921b828eb6f3e95faa.camel@linux.ibm.com>
         <4866a6ef46deebf9a9afdeb7efd600edb589da93.camel@huaweicloud.com>
         <102b06b30518ac6595022e079de92717c92f3b8e.camel@linux.ibm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
User-Agent: Evolution 3.44.4-0ubuntu2 
MIME-Version: 1.0
Precedence: bulk

On Thu, 2023-10-12 at 13:10 -0400, Mimi Zohar wrote:
> > > > > > We need to make sure that ima_post_path_mknod() has the
> > > > > > same parameters
> > > > > > as the LSM hook at the time we register it to the LSM
> > > > > > infrastructure.
> > > > > 
> > > > > I'm trying to understand why the pre hook parameters and the
> > > > > missing
> > > > > IMA parameter are used, as opposed to just defining the new
> > > > > post_path_mknod hook like IMA.
> > > > 
> > > > As an empyrical rule, I pass the same parameters as the
> > > > corresponding
> > > > pre hook (plus idmap, in this case). This is similar to the
> > > > inode_setxattr hook. But I can be wrong, if desired I can
> > > > reduce.
> > > 
> > > The inode_setxattr hook change example is legitimate, as EVM
> > > includes
> > > idmap, while IMA doesn't. 
> > > 
> > > Unless there is a good reason for the additional parameters, I'm
> > > not
> > > sure that adding them makes sense.  Not modifying the parameter
> > > list
> > > will reduce the size of this patch set.
> > 
> > The hook is going to be used by any LSM. Without knowing all the
> > possible use cases, maybe it is better to include more information
> > now,
> > than modifying the hook and respective implementations later.
> > 
> > (again, no problem to reduce)
> 
> Unless there is a known use case for a specific parameter, please
> minimize them.   Additional parameters can be added later as needed. 

Ok. I did the same for inode_post_create_tmpfile.

Thanks

Roberto