[Unionfs] ERROR: "security_inode_permission" [fs/unionfs/unionfs.ko] undefined!

[Jacob]

On Tue, 10 Mar 2009 16:45:32 -0400
"David P. Quigley" <dpquigl at tycho.nsa.gov> wrote:

> On Tue, 2009-03-10 at 12:04 -0400, Jacob wrote:
> > I am using linux-2.6.27-gentoo-r8, with the "unionfs-2.5.1_for_2.6.27.10" patch applied, and I get the following error right at the end:
> > 
> > === BEGIN ===
> > Kernel: arch/x86/boot/bzImage is ready  (#1)
> >   Building modules, stage 2.
> >   MODPOST 69 modules
> > ERROR: "security_inode_permission" [fs/unionfs/unionfs.ko] undefined!
> > make[1]: *** [__modpost] Error 1
> > make: *** [modules] Error 2
> > === END ===
> > 
> > I have done some research, and the following patch was created:
> > 
> > === BEGIN ===
> > --- a/security/security.c       2009-03-10 11:49:11.000000000 -0400
> > +++ b/security/security.c       2009-03-10 11:49:47.000000000 -0400
> > @@ -439,6 +439,7 @@
> >                 return 0;
> >         return security_ops->inode_permission(inode, mask);
> >  }
> > +EXPORT_SYMBOL(security_inode_permission);
> >  
> >  int security_inode_setattr(struct dentry *dentry, struct iattr *attr)
> >  {
> > @@ -554,6 +555,7 @@
> >  {
> >         return security_ops->file_ioctl(file, cmd, arg);
> >  }
> > +EXPORT_SYMBOL(security_file_ioctl);
> >  
> >  int security_file_mmap(struct file *file, unsigned long reqprot,
> >                         unsigned long prot, unsigned long flags,
> > === END ===
> > 
> > With this patch, I no longer receive the above errors. However, as I understand it, this is a hackish way to fix the problem, which is that unionfs shouldn't even be using these "symbols" (of which I know nothing about :) directly in the first place.
> > 
> > Is there any known solution to this problem?
> > 
> > _______________________________________________
> > unionfs mailing list: http://unionfs.filesystems.org/
> > unionfs at mail.fsl.cs.sunysb.edu
> > http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
> 
> 
> Why is it that you think that Unionfs shouldn't be calling
> security_inode_permission? the security_* functions are the proper
> interface to make calls to whatever LSM is loaded. I think its
> reasonable to export that symbol for use in a module if Unionfs really
> needs to be calling that function. The question is however, is there a
> reason unionfs is calling this because it should normally be called
> through permission() which should be hit somewhere in the VFS before you
> get to the Unionfs inode.

I cannot argue with you very reasonably, because I am not a kernel developer. I depend entirely on others' opinions, such as these messages:
http://lkml.org/lkml/2007/10/22/55
http://kerneltrap.org/mailarchive/linux-kernel/2007/10/23/350927

And another interesting message to consider:
http://kerneltrap.org/mailarchive/linux-kernel/2007/10/27/362612

Anyway, if you guys say it's good, it's good, and it's applied to my kernel source. :)

-- 
    Jacob

    "For then there will be great distress, unequaled
    from the beginning of the world until now—and never
    to be equaled again. If those days had not been cut
    short, no one would survive, but for the sake of the
    elect those days will be shortened."
    
    Are you ready?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://www.fsl.cs.sunysb.edu/pipermail/unionfs/attachments/20090310/8be33cb3/signature.bin