Re: [patch 01/15] security: pass path to inode_create

Miklos Szeredi
2008-06-03T06:09:54Z

> 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