On Tue, Dec 11, 2012 at 8:35 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Dec 11, 2012 at 10:12 AM, Kasatkin, Dmitry > <dmitry.kasatkin@xxxxxxxxx> wrote: >> >> Actually S_PRIVATE does not work work for normal filesystems which IMA >> might want to ignore. > > The reading comprehension here is abysmal. > > First you claim that you need the new flag for pseudo-filesystems, and > now that I point out that we have an *old* flag for pseudo-filesystems > you turn around 180 degrees and talk about other filesystems. > I have not claimed that. This is exactly what I have written: "There are different filesystems which are not checked by IMA/EVM, such as pseudo-filesystems" Pseudo-filesystems was an example of possible cases. Sorry if it was not clear enough. > And none of that matters for my argument AT ALL. > > My argument has not been that we cannot add a new flag. > > My argument has been that we already have the logical place for such a > flag, and that adding a totally new field seems so stupid. > > Seriously. The i_flags place is where we already do pretty much > *exactly* what you ask for. The fact that it is faster and more > flexible to boot should be a bonus. > > Now, there are real reasons to avoid "s_flags", notably the fact that > we're running out of bits there (unlike i_flags), and they are exposed > as generic fields and are generally meant for mount options etc. So I > understand why we might want to avoid that (although the whole > mount-option thing could also be seen as an advantage), but I really > don't see any argument against i_flags, considering that we already > use it for S_IMA and S_PRIVATE, both of which are related to exactly > what you seem to want to do. Not every inode on the filesystem might be checked by IMA. It depends on policy. And S_IMA flag is used exactly for this purpose. But when the entire FS is not checked, SB flag seems to be very appropriate. Eric has given nice explanation. > > The one downside of i_flags may be that any update should own the > inode semaphore. But within the context of a security model, that > should be fine (and normally you'd update it once per lifetime of the > inode). > This is exactly how IMA works at the moment. See my response to Eric about performance. > Linus -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
