[Unionfs] ERROR: "security_inode_permission"
[fs/unionfs/unionfs.ko] undefined!
David P. Quigley
dpquigl at tycho.nsa.gov
Tue Mar 10 16:45:32 EDT 2009
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.
Looking at the unionfs-latest.git tree that Erez has shows a fix for
this and the reason why they can't rely on permission checking higher
up. You can find it in commit 232acbbfb3ae54ae7521e9b5eb1051261469831b.
"Security/VFS: re-export security_inode_permission symbol
Unionfs needs it because it has to do everything in there, but skip the
EROFS test (so copyup can be triggered). There's no easy way to execute
parts of security_inode_permission() without copying and duplicating
much of its functionality, so exporting the symbol seems the simplest."
Dave
More information about the unionfs
mailing list