Re: [RFC] Virtualization steps

[Sam Vilain]

Chris Wright wrote:

>* Sam Vilain (sam@xxxxxxxxxx) 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/