On Tue, Dec 11, 2012 at 12:55 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > And your "pseudo-filesystems" argument is pretty stupid too, since WE > ALREADY HAVE A FLAG FOR THAT! > > Guess where it is? Oh, it's in the place I already mentioned makes > more sense. Look for S_PRIVATE in inode->i_flags, and IS_PRIVATE() in > users. It's what the other security models already use to avoid > bothering calling down to the security layers. The fact that the > integrity layer bypasses the normal security layer in > ima_file_check(), for example, is no excuse to then make up totally > new flags. IS_PRIVATE() is not used by and darn well better not be used by, all psuedo filesystems like procfs which IMA may want to ignore. LSMs like to do control on them. I thought S_PRIVATE was really only used by the anon_inode and reiserfs's really crazy ass internal inodes. I could always be wrong. I don't know if I agree with dmitry but let me explain what's going on here. Lets say the user accesses an inode in procfs. Without this patch one would search the ima policy and find a rule that says 'if this inode is on procfs we don't care.' We can then cache that in the struct inode like you say and move along. If another inode on procfs is opened we will have the same policy search and the same per inode 'i don't give a crap' marking. This absolutely works you are right. But we search the IMA policy for every inode. With Dmitry's patch we can instead search the IMA policy one time and mark the whole superblock as 'i don't give a crap' if IMA policy says we don't care about that fstype. When the second procfs inode is opened we instead look at the per superblock 'who gives a crap' and never search the IMA policy. So we save all future policy searches. I'd say this patch would only be a good idea if there is a real performance hit which is measurable in a real work situation. Not, 'look how much faster it is to access proc inodes' microbenchmark, since noone is actually going to do that, but some results of a useful benchmark you care about. Maybe Dmitry gave those numbers and I missed them? Otherwise, stick with per inode like Linus wants... -- 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
