On Tue, Dec 11, 2012 at 8:09 PM, Eric Paris <eparis@xxxxxxxxxxxxxx> wrote: > 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... I was measuring that during on the system without super block flag, policy search was happening 100 000 times, but with the flag just bellow 10 000. For desktop multi-core systems powered from the plug it might be unnoticeable. But for the handhald it might save the battery. - Dmitry -- 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
