Messages in this thread | | | Date | Thu, 30 Mar 2006 11:01:32 +1200 | From | Sam Vilain <> | Subject | Re: [RFC] Virtualization steps |
| |
Chris Wright wrote:
>* Sam Vilain (sam@vilain.net) wrote: > > >>extern struct security_operations *security_ops; in >>include/linux/security.h is the global I refer to. >> >> > >OK, I figured that's what you meant. The top-level ops are similar in >nature to inode_ops in that there's not a real compelling reason to make >them per process. The process context is (usually) available, and more >importantly, the object whose access is being mediated is readily >available with its security label. > >
AIUI inode_ops are not globals, they are per FS.
>>There is likely to be some contention there between the security folk >>who probably won't like the idea that your security module can be >>different for different processes, and the people who want to provide >>access to security modules on the systems they want to host or consolidate. >> >> > >I think the current setup would work fine. It's less likely that we'd >want a separate security module for each container than simply policy >that is container aware. > >
That to me reads as:
"To avoid having to consider making security_ops non-global we will force security modules to be container aware".
It also means you could not mix security modules that affect the same operation different containers on a system. Personally I don't care, I don't use them. But perhaps this inflexibility will bring problems later for some.
I think it's a design decision that is not completely closed, but the inertia is certainly in the favour of your position.
Sam. - 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/
| |