Messages in this thread | | | Date | Thu, 20 Apr 2006 09:46:51 -0700 | From | Greg KH <> | Subject | Re: Removing EXPORT_SYMBOL(security_ops) (was Re: Time to remove LSM) |
| |
On Thu, Apr 20, 2006 at 12:34:57PM -0400, Stephen Smalley wrote: > On Thu, 2006-04-20 at 17:23 +0100, Christoph Hellwig wrote: > > On Thu, Apr 20, 2006 at 09:15:52AM -0700, Greg KH wrote: > > > On Thu, Apr 20, 2006 at 10:20:11AM -0400, Stephen Smalley wrote: > > > > On Thu, 2006-04-20 at 08:00 -0700, Greg KH wrote: > > > > > I agree. In looking over the code some more, I'm trying to figure out > > > > > why we are exporting that variable at all. Is it because of people > > > > > wanting to stack security modules? > > > > > > > > > > I see selinux code using it, but you are always built into the kernel, > > > > > right? So unexporting it would not be an issue to you. > > > > > > > > Various in-tree modules (e.g. ext3) call security hooks via the static > > > > inlines and end up referencing security_ops directly. We'd have to wrap > > > > all such hooks in the same manner as capable and permission. > > > > > > Ah, and people like making their file systems as modules :( > > > > But actually yes, calling into rndom lsm hooks in modules is not a good > > thing.a The only think filesystems calls is security_inode_init_security > > and it would make a lot of sense to make that an out of line wrapper > > instead of exporting security_ops. > > There are other cases as well, I think, e.g. af_unix calls certain hooks > to ensure mediation of even the abstract namespace. But the problem is > avoided altogether if the security static inlines compile down to direct > selinux function calls (which can be exported as needed).
Of course it's "avoided alltogether" but we are not talking about dropping the whole LSM interface here right now. I am wanting something that can go into 2.6.17 to fix this issue this week.
thanks,
greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |