From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: IMA policy search speedup Date: Wed, 19 Sep 2012 05:46:51 +0100 Message-ID: <20120919044651.GY13973@ZenIV.linux.org.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Kasatkin, Dmitry" , Linus Torvalds , linux-fsdevel@vger.kernel.org, linux-security-module , LKML , Mimi Zohar To: James Morris Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:52456 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754585Ab2ISErA (ORCPT ); Wed, 19 Sep 2012 00:47:00 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Sep 19, 2012 at 02:21:56PM +1000, James Morris wrote: > On Tue, 18 Sep 2012, Kasatkin, Dmitry wrote: > > > I looked to and found that there is a possibility to to > > add additional flag for sb->s_flags. > > For example > > > > #define MS_NOT_IMA (1<<25) /* NOT_IMA */ > > #define IS_I_NOT_IMA(inode) __IS_FLG(inode, MS_NOT_IMA) > > > > > > Another way is to add additional dedicated integrity related member to > > the sb structure. > > struct super_block { > > ... > > #ifdef CONFIG_INTEGRITY > > int s_integrity; > > #endif > > }; > > > > Obviously there are only few super blocks in the system and few bytes > > will not harm. > > The flag seems better than adding a new struct member. Why would you need > an int for this? Per-superblock bit would be a bit better, but I really hate the way we have them mixed up between superblock ->s_flags bits and mount(2) action weirdly encoded into flags thing. If we are going to touch that thing, how about separate S_... bits, with MS_... crap left only for mount(2) decoding? Mapped to S_... when needed. The really messy part is that right now we silently ignore all the unknown bits in mount(2) flags argument ;-/ It's *not* a widely used syscall, but still - changing that in a non-trivial way is potential userland breakage.