Re: Containers and /proc/sys/vm/drop_caches

[Serge Hallyn <serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>]

Quoting Daniel Lezcano (daniel.lezcano-GANU6spQydw@public.gmane.org):
> On 01/05/2011 10:40 AM, Mike Hommey wrote:
> >[Copy/pasted from a previous message to lkml, where it was suggested to
> >  try containers@]
> >
> >Hi,
> >
> >I noticed that from within a lxc container, writing "3" to
> >/proc/sys/vm/drop_caches would flush the host page cache. That sounds a
> >little dangerous for VPS offerings that would be based on lxc, as in one
> >VPS instance root user could impact the overall performance of the host.
> >I don't know about other containers but I've been told openvz isn't
> >subject to this problem.
> >I only tested the current Debian Squeeze kernel, which is based on
> >2.6.32.27.
> 
> There is definitively a big work to do with /proc.
> 
> Some files should be not accessible (/proc/sys/vm/drop_caches,
> /proc/sys/kernel/sysrq, ...) and some other should be virtualized
> (/proc/meminfo, /proc/cpuinfo, ...).
> 
> Serge suggested to create something similar to the cgroup device
> whitelist but for /proc, maybe it is a good approach for denying
> access a specific proc's file.

Long-term, user namespaces should fix this - /proc will be owned
by the user namespace which mounted it, but we can tell proc to
always have some files (like drop_caches) be owned by init_user_ns.

I'm hoping to push my final targeted capabilities prototype in the
next few weeks, and after that I start seriously attacking VFS
interaction.

In the meantime, though, you can use SELinux/Smack, or a custom
cgroup file does sound useful.  Can cgroups be modules nowadays?
(I can't keep up)  If so, an out of tree proc-cgroup module seems
like a good interim solution.

-serge