[Lxc-users] restricting container visible cpus

Daniel Lezcano daniel.lezcano at free.fr
Mon Mar 15 12:03:03 UTC 2010

atp wrote:
> Daniel,
>> Not really. I think we should create a single daemon on the host 
>> providing services for the container, but there is the isolation 
>> preventing us to do that easily, so I don't have yet a clear idea of how 
>> to do that.
>   Ok, fair enough. I'll proceed with the setup as it stands then. My
> initial target will be to fix meminfo, and mask /proc/cpuinfo
> and /proc/stat. 
>   You need something that can bridge the gap, and represent a masked
> view of the host /proc into the container, using context from the
> control group of that container. That implies that there is something
> running in the host thats mounted in the container /proc. 
>   I understand your points below about not changing /proc in the kernel,
> but if lxc is to be a replacement for openvz, then the isolation of the
> container needs to be improved. There's nothing to stop a container
> admin mounting the hosts /proc filesystem, unless there's something
> in the kernel to steer them in the right direction. I view this not as 
> virtualisation, but more as isolation, which is in the remit of a
> container. 
Preventing the container to [um]mount /proc again can be handled with a 
smack policy no ?

I recall a discussion about that (end of the thread).


>   For that reason, I think that a kernel module makes the most sense in
> the long run, if the core kernel can't be modified. For now, I'll work
> on the procfs fuse module. 
>   I'll post up my changes in a day or so. 
Ok, cool. I will stay tuned.

  -- Daniel

More information about the lxc-users mailing list