> Quoting Kentaro Takeda (
takedakn@nttdata.co.jp):
> > Al, could you answer the following question?
> >
> >
> > The current Linux kernel is not designed to pass vfsmount parameter
> > that is crucial for pathname-based security including AppArmor and
> > TOMOYO Linux, to LSM. Though both projects have been proposing
> > patches to calculate pathname, none of them have been accepted as
> > you know.
> >
> > To find the reason for NACK, we examined past proposals and the
> > threads. And we came to understand that you oppose accessing vfsmount
> > inside vfs helper functions. Is our understanding correct?
> >
> > If our understanding is correct, we would like to propose a new
> > method that does not require modifications to vfs helper functions.
> > Attached patch is a trial of this method.
> >
> > vfs helper functions are surrounded by mnt_want_write() and
> > mnt_drop_write() pairs which receive "struct vfsmount" parameter
>
> I thought Al and others (Stephen?) had made it clear that the thing to do was
> add new lsm hooks there. So whereas inode_permission takes only an inode and
> ends up calling security_inode_permission, you would add a
> security_path_permission() or somesuch before or after the call to
> inode_permission(), where as you've noted the path is available. You're
> *close* to doing the right thing by having a helper who is called at the right
> place catch the vfsmount, but you refuse to send a patch doing exactly what
> has been suggested.