Re: Constraining the memory used by an unprivilged mount of tmpfs.

[Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>]

On 01/18/2013 11:48 AM, Serge Hallyn wrote:
> Quoting Glauber Costa (glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org):
>> 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.

Again, I am not concerned with sane setups in here, but much more with
normal users in normal systems taking advantage of this.