[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).
https://lists.linux-foundation.org/pipermail/containers/2009-August/020205.html
> 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.
Thanks
-- Daniel
More information about the lxc-users
mailing list