On Mon, Oct 22, 2007 at 08:48:04PM -0400, Erez Zadok wrote: > Why? Are you concerned that the security policy may change after a module > is loaded? No, it's a matter of proper layering. We generally don't want modules like stackabke filesystems to call directly into methods but rather use proper highlevel VFS helpers to isolate them from details and possible changes. The move to out of line security_ helpers just put this on the radard. > I can probably get rid of having unionfs call security_inode_permission, by > calling permission() myself and carefully post-process its return code > (unionfs needs to "ignore" EROFS initially, to allow copyup to take place). Sounds fine. > But security_file_ioctl doesn't have any existing helper I can call. I can > introduce a trivial vfs_security_file_ioctl wrapper to security_file_ioctl, > but what about the already existing *19* exported security_* functions in > security/security.c? Do you want to see simple wrappers for all of them? > It seems redundant to add a one-line wrapper around an already one-line > function around security_ops->XXX. Plus, some of the existing exported > security_* functions are file-system related, others are networking, etc. So > we'll need wrappers whose names are prefixed appropriately: vfs_*, net_*, > etc. The fix for security_file_ioctl is probably to either not do it at all or move it the call to security_file_ioctl into vfs_ioctl and get it by using that helper. I suspect most other security_ exports should be avoided similarly. I also suspect the whole issue of where and how-many times to call LSM methods for stackable filesystems is a huge can of worms and it might make sense to talk to the LSM folks about it. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
