On Fri, Mar 21, 2008 at 05:24:11PM +0100, Miklos Szeredi wrote:
quoted text
> > > I know there are a few cases, where filesystems call vfs_foo()
> > > internally, where the vfsmount isn't available, but I think the proper
> > > solution is just to fix those places, and not recurse back into the
> > > VFS (which is AFAICS in all those cases totally unnecessary anyway).
> > > This would make everybody happy, no?
> > 
> > Apparmor can go play with itself.  The proper fix is to lift the LSM nonsense
> > into callers and leave vfs_...() alone;
> 
> Maybe.  I know precious little about this security thing, so I won't
> argue about it's merits or faults.  But:
> 
>  a) I have a hunch that the security guys wouldn't like to see the
>  order between permission() and security_foo() changed.

It's their problem.  Adjusting LSM methods, if needed, is up to LSM
maintainers, whenever moving the hooks or code around those become
convenient for kernel proper.  According to Linus, IIRC.

Especially since in this case they want to change prototypes anyway, so the
churn is not an issue and having the hook called earlier is very unlikely to
cause any problems.

quoted text
>  b) I fail to see how moving functionality to callers would improve
>  things
> 
> > vfsmounts should *not* be passed there at all, with the exception of
> > vfs_follow_link() which gets the full nameidata.
> 
> Why?

Because filesystem shouldn't _care_ where it is mounted.  Anything
vfsmount-dependent belongs to upper layers.  The same goes for passing
nameidata to fs methods, BTW - again, ->follow_link() is an obvious
legitimate exception.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/