--
This post is a request for discussion on creating a second smaller
nameidata struct to eliminate conditionally passing of vfsmounts
to the LSM.
It contains a series of patches that apply on top of the AppArmor
patch series. These patches were previously post on May 14,
but received no feedback. Any and all feedback is welcome so
that we can improve these patches or replace them with a better
solution if one presents it self.
To remove conditionally passing of vfsmounts to the LSM, a nameidata
struct can be instantiated in the nfsd and mqueue filesystems. This
however results in useless information being passed down, as not
all fields in the nameidata struct will be meaingful. The nameidata
struct is split creating struct nameidata2 that contains only the fields
that will carry meaningful information.
The creation of the nameidata2 struct raises the possibility of
replacing the current dentry, vfsmount argument pairs in the
vfs and lsm patches with a single nameidata2 argument although these
patches do not currently do this.
A tarball of these patches and the AppArmor kernel patches are
available at:
http://forgeftp.novell.com//apparmor/LKML_Submission-June-07/
On Tue, 2007-06-26 at 16:15 -0700, [email protected] wrote:
> To remove conditionally passing of vfsmounts to the LSM, a nameidata
> struct can be instantiated in the nfsd and mqueue filesystems. This
> however results in useless information being passed down, as not
> all fields in the nameidata struct will be meaingful. The nameidata
> struct is split creating struct nameidata2 that contains only the
> fields
> that will carry meaningful information.
I don't object to the concept per se, but could you please give it a
more descriptive name please? "struct vfs_intent" would be a lot more
accurate than "nameidata2".
Trond
On Wednesday 27 June 2007 01:46, Trond Myklebust wrote:
> On Tue, 2007-06-26 at 16:15 -0700, [email protected] wrote:
> > To remove conditionally passing of vfsmounts to the LSM, a nameidata
> > struct can be instantiated in the nfsd and mqueue filesystems. This
> > however results in useless information being passed down, as not
> > all fields in the nameidata struct will be meaingful. The nameidata
> > struct is split creating struct nameidata2 that contains only the
> > fields
> > that will carry meaningful information.
>
> I don't object to the concept per se, but could you please give it a
> more descriptive name please? "struct vfs_intent" would be a lot more
> accurate than "nameidata2".
Yes, the name is pretty arbitrary. vfs_intent is better, even though the
struct doesn't only include the intent data.
Thanks,
Andreas
On Tue, Jun 26, 2007 at 07:46:15PM -0400, Trond Myklebust wrote:
> I don't object to the concept per se, but could you please give it a
> more descriptive name please? "struct vfs_intent" would be a lot more
> accurate than "nameidata2".
Agreed, but I prefer lookup_intent - intent by itself is a word with
just to wide useage and vfs doesn't make it much clearer..