On Tue, Jun 03, 2008 at 12:31:14AM +0900, Toshiharu Harada (haradats@xxxxxxxxx) wrote: > > This is a really interesting flame, can you proceed, > > we will run for cola and peanuts :) > > Let me quote a message by Chris Wright from LSM ml: > "You cannot discover the path used to access an inode without knowing > both the dentry and the vfsmount objects. " Depending on what path you really want. If you want it related to bind mount, you can (trivially). And even full path with vfsmount with additional work. Without any single additional patch on top of security system. It maybe a bit slower, more complex, duplicate, whatever... Active security was never a fast solution and was never a compromiss between those who like it and who do not. Technically you can be inside created limits and formally do not change security model, but in practice implement you lovely path based security checks. > Another one by Stephen Smalley: > "Pathname-based security considered harmful. You want to control access > to an object, not a name, and the name-to-object mapping is neither > one-to-one nor immutable." For those who care exactly about path, they do not want to have security checks for object, which was there. As addition, selinux maintainer/architector opinion is a bit biassed :) > Can you guess when they were posted? > The answer is December 2003. :) > Do we need more time? I don't think so. Apparently we do :) > I'm viewing Miklos' patches as *enhancements* not only for AppArmor (and > other pathname-based LSM modules). Everyone can make use of > information and lose nothing. Am I too simple minded? What I wanted to say, is that people who do want to implement theirs idea, will find a way to do it without breaking other approach. With additional changes, with more complex approach, more code and possibly some duplication/optimization/whatever. So, if people continue to kick theirs head to the wall, they want exactly that flame, that void talks and so on :) -- Evgeniy Polyakov -- 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
