On Tue, Dec 11, 2012 at 7:55 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Dec 11, 2012 at 9:40 AM, Kasatkin, Dmitry > <dmitry.kasatkin@xxxxxxxxx> wrote: >>> >>> Quite frankly, this seems stupid. >> >> What exactly seems stupid here? > > What I said. Go back and read it. I gave three reasons. Why do you ask? > > I'll give one more reason, but you probably won't read *this* email > either, will you? > No comments. Should I say more here? Better read further... >> There are different filesystems which are not checked by IMA/EVM, >> such as pseudo-filesystems. > > Did you read my email? > > There are probably *also* individual that aren't checked by IMA/EVM > even on filesystems that *do* check other files. > > No? > > 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. > > So let me repeat: adding a new superblock flag seems STUPID. Why is it > in a completely different place than all the other flags that we > already have for these kinds of things? Why should we add a new field, > when we have existing fields that seem to do exactly this, do it > better, and are already used? > I was suggesting to add a flag for sb->s_flags field. Al said that he would not like this, because s_flags are mount specific. One of suggestions in response was to use s_feature flags, because other FSs would benefit from that as well.. https://lkml.org/lkml/2012/9/19/460 > And don't ask me why without reading this email. OK? Again, no comments. > > 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
