From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic301-26.consmr.mail.ir2.yahoo.com ([77.238.176.103]:38388 "EHLO sonic301-26.consmr.mail.ir2.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726735AbeJDLki (ORCPT ); Thu, 4 Oct 2018 07:40:38 -0400 Subject: Re: [PATCH v4 14/19] LSM: Infrastructure management of the inode security To: James Morris , Kees Cook Cc: LSM , SE Linux , LKLM , John Johansen , Tetsuo Handa , Paul Moore , Stephen Smalley , "linux-fsdevel@vger.kernel.org" , Alexey Dobriyan , =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= , Salvatore Mesoraca References: From: Casey Schaufler Message-ID: <6243a363-e15a-e3fe-37ce-fb4c0a150873@schaufler-ca.com> Date: Wed, 3 Oct 2018 21:49:06 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 10/3/2018 11:13 AM, James Morris wrote: > On Fri, 21 Sep 2018, Kees Cook wrote: > >> On Fri, Sep 21, 2018 at 5:19 PM, Casey Schaufler wrote: >>> + * lsm_early_inode - during initialization allocate a composite inode blob >>> + * @inode: the inode that needs a blob >>> + * >>> + * Allocate the inode blob for all the modules if it's not already there >>> + */ >>> +void lsm_early_inode(struct inode *inode) >>> +{ >>> + int rc; >>> + >>> + if (inode == NULL) >>> + panic("%s: NULL inode.\n", __func__); >>> + if (inode->i_security != NULL) >>> + return; >>> + rc = lsm_inode_alloc(inode); >>> + if (rc) >>> + panic("%s: Early inode alloc failed.\n", __func__); >>> +} >> I'm still advising against using panic(), but I'll leave it up to James. >> > Calling panic() is not appropriate here. Perhaps if it was during > boot-time initialization of LSM infrastructure, but not on the fly. Tetsuo's patch makes this an __init function. It's only for doing init time stuff like root inode initialization during start-up. If it fails the caller is going to have to panic. This came straight out of the SELinux system initialization code. I could go back to having each LSM do it's own panic, but that seems silly. > > Use a WARN_ONCE then propagate the error back and fail the operation. > >