Constraining the memory used by an unprivilged mount of tmpfs.

Serge E. Hallyn serge at hallyn.com
Sun Jan 20 19:27:24 UTC 2013


Quoting Glauber Costa (glommer at parallels.com):
> On 01/18/2013 11:48 AM, Serge Hallyn wrote:
> > Quoting Glauber Costa (glommer at parallels.com):
> >> On 01/17/2013 11:01 PM, Eric W. Biederman wrote:
> >>> What are the practical problems with control groups that makes them
> >>> undesirable/hard to use with namespaces?
> >>>
> >>> What would it take to fix the problems with control groups?
> >> There aren't, from my PoV.
> >> When I run containers, for instance, I basically join all namespaces,
> >> configure all groups, and everything I can.
> >>
> >> I do know, however, that not every use case is like that, and those
> >> things tends to be very loosely coupled.
> >>
> >> So what I am worried about, is not a valid container usage where you
> >> have your constraints configured. But if I login into a box as a normal
> >> user, and that now allows me to create a userns, and maliciously fire a
> >> big tmpfs from there, cgroups will not gonna be there for me - it's not
> >> a container box, is just something I am trying to break.
> > 
> > Hm.  So basically we would, ideally, find a way to make it so that if
> > uid 500 creates a new userns and, therein, mounts a tmpfs, then that
> > tmpfs gets accounted and limited along with uid 500's RSS?
> > 
> 
> Dunno.
> 
> One option would be to start establishing stronger connections between
> cgroups and namespaces in a sane way. And then, we only allow such
> mounts when you are actually cgroup backed.

The latter is probably not horrible - I'm all for encouraging distros
to start always setting up cgroups on login.

-serge


More information about the Containers mailing list