Serge E. Hallyn wrote:
quoted text
> Quoting Pavel Emelyanov (xemul@openvz.org):
>> Serge E. Hallyn wrote:
>>> Quoting James Morris (jmorris@namei.org):
>>>> On Thu, 13 Mar 2008, Serge E. Hallyn wrote:
>>>>
>>>>> Quoting James Morris (jmorris@namei.org):
>>>>>> On Thu, 13 Mar 2008, Serge E. Hallyn wrote:
>>>>>>
>>>>>>> True, but while this change simplifies the code a bit, the semantics
>>>>>>> seem more muddled - devcg will be enforcing when CONFIG_CGROUP_DEV=y
>>>>>>> and:
>>>>>>>
>>>>>>> 	SECURITY=n or
>>>>>>> 	rootplug is enabled
>>>>>>> 	capabilities is enabled
>>>>>>> 	smack is enabled
>>>>>>> 	selinux+capabilities is enabled
>>>>>> Well, this is how real systems are going to be deployed.
>>>>> Sorry, do you mean with capabilities?
>>>> Yes.
>>>>
>>>> All Fedora, RHEL, CentOS etc. ship with SELinux+capabilities.  I can't 
>>>> imagine not enabling them on other kernels.
>>>>
>>>>>> It becomes confusing, IMHO, if you have to change which secondary LSM you 
>>>>>> stack with SELinux to enable a cgroup feature.
>>>>> So you're saying selinux without capabilities should still be able to
>>>>> use dev_cgroup?  (Just making sure I understand right)
>>>> Nope, SELinux always stacks with capabilities, so havng the cgroup hooks 
>>>> in capabilities makes sense (rather than having us change the secondary 
>>>> stacking LSM just to enable a feature).
>>> Oh, ok.
>>>
>>> Will let the patch stand until Pavel and Greg comment then.
>> Well, I saw your previous patch, that was implemented as just another
>> LSM module and I liked it except for the LSM dependency.
> 
> James and Stephen agree with your LSM qualms.  I suppose we could add

Thanks!

quoted text
> cgroups next to the lsm hooks.  I suspect Paul Menage would complain
> about that (Paul?), and I do think it's silly as they are security
> questions, not group tracking questions, but if it's what people want
> I can send out a new patch next week.

The way I see this is: cgroups provide a common way to group tasks
and an API for general configuration - that's the controller "face", 
and it's up to the controller to decide where he turns his "back",
IOW where the hooks are placed. For the memory controller - they are
injected directly into the mm code. For this controller, I think it
would be OK to use LSM or about-LSM hooks.

quoted text
>> Since this version can happily work w/o LSM, I like it too :)
> 
> In an earlier version I asked whether you had any experience with usual
> # rules per container.  Do you have an idea?  Right now the whitelist is
> a straight list we search through linearly.  If # rules is generally
> tiny then I'm inclined to keep it that way...

The # of rules usually has a linear dependency on the number of containers
(each of then has to have an access to /dev/null,zero,random at least), so
having 100 containers we will have to scan through a 300-entries list. I'd
vote for a hash table or a radix/binary/rb tree for that. Or any other way
for non-linear search you can provide :)

quoted text
> thanks,
> -serge
> 

--
unsubscribe notice
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/