> Actually, another option has been suggested last month. > http://lkml.org/lkml/2008/4/9/93 Yes, thanks for the link. Here's the relevant quote from that mail from Stephen Smalley: "2) Submit patches to add new security hooks to the callers where the vfsmount is already available (some have suggested moving the existing security_inode hooks to the callers, but that would cause problems for SELinux as I've posted elsewhere, so adding new hooks is preferable, and then SELinux can just default to the dummy functions for those new hooks)." True, this is an alternative, but from the VFS point of view it's actually _worse_ than moving the hooks out, since we now have two sets of security hooks littering the code for no good reason. If Matthew Wilcox's idea can be made to work, that's obviously the best, since it means that the VFS doesn't need to be touched at all. Otherwise passing down vfsmounts is a superior solution to everything else. It has *absolutely* *no* downsides. None, zero, zilch. Well apart from the matter of VFS maintainers opinions. But damit, this is an open source project, where decisions are made on technical merit, and not on personal whims. If the VFS maintainers don't like it, they better state their reasons in clear and concise terms. An no, things like "someone might perhaps maybe in the future need to call the vfs without a vfsmount" is absolutely not a good reason. When we have such a caller, we'll fix the code. It happens all the time. Prepering for everything that might happen is called overdesign and it's one of the worst and commonest mistakes in software engineering. Miklos -- 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
