[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwA3isRny9JyqxzjoysHbRhiKpBheeEi6VZrnWokt521A@mail.gmail.com>
Date: Tue, 11 Dec 2012 08:59:01 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc: "Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>,
Al Viro <viro@...iv.linux.org.uk>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
LSM List <linux-security-module@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
James Morris <jmorris@...ei.org>
Subject: Re: [PATCH 0/2] ima: policy search speedup
On Tue, Dec 11, 2012 at 6:08 AM, Mimi Zohar <zohar@...ux.vnet.ibm.com> wrote:
> On Tue, 2012-12-11 at 14:51 +0200, Kasatkin, Dmitry wrote:
>> >>
>> >> Two months ago I was asking about it on mailing lists.
>> >> Suggestion was not to use s_flags, but e.g. s_feature_flags.
Quite frankly, this seems stupid.
Without really knowing the problem space, the sane thing to do would
seem to be inode->i_flags. At which point it's
(a) faster to test (no need to dereference inode->i_sb)
(b) matches what the integrity layer does with S_IMA (well, there the
logic is reversed: S_IMA means that it has a integrity structure
associated with it)
(c) allows you to mark individual inodes as "no checking".
and quite frankly, (c) in particular seems to make sense to me, since
it would seem to be rather possible to do things like "I've checked
this inode, it had no policies associated with it, I never need to
check it again". Clear the flag when policies change or whatever.
What's the advantage of making it per-filesystem?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists