[PATCH RESEND] userns: enable tmpfs support for user namespace

[Glauber Costa]

On 01/21/2013 06:39 AM, Gao feng wrote:
> On 2013/01/18 13:33, Glauber Costa wrote:
>> On 01/17/2013 09:29 PM, Eric W. Biederman wrote:
>>> Serge Hallyn <serge.hallyn at canonical.com> writes:
>>>
>>>> Quoting Eric W. Biederman (ebiederm at xmission.com):
>>>>> Serge Hallyn <serge.hallyn at canonical.com> writes:
>>>>>
>>>>>> I actually was waiting for Eric to do it, but I'll happily send it
>>>>>> to linux-fsdevel and lkml (in a bit).
>>>>>
>>>>> I might just.
>>>>>
>>>>> I will take a look at this in a week or so.  I want to get through the
>>>>> core userspace bits first so I can just cross those off my list of
>>>>> things that need to be done.
>>>>>
>>>>> Eric
>>>>
>>>> Ok, I'll wait on sending it then - thanks.
>>>
>>> Next up is my patch to shadow-utils and then taking a good hard stare at
>>> what is left kernel side.
>>>
>>> One of the questions I need to answer is:  Do cgroups actually work
>>> for what needs to be limited?  Or does the the focus of cgroups on
>>> processes without other ownership in objects fundamentally limit what
>>> can be expressed with cgroups in a problematic way.  In which case would
>>> some hierarchical limits based on user namespaces and rlimits be easier
>>> to implement and make more sense.
>>>
>>> I think the answer will be that cgroups are good enough but that
>>> question certainly needs looking at.
>>>
>>> Anyway.  shadow-utils, minimal tmpfs, minimal devpts, and then the rest.
>>>
>> First easy question:
>>
>> cgroups are not necessarily configured.
>>
>> IIUC, the aim of this patch is to allow unprivileged mounts of tmpfs
>> relying on the fact that cgroups will stop memory abuse (correct me if I
>> am wrong).
>>
>> But what if the user is not using cgroups?
>>
> 
> I think maybe we can force config MEMCG being selected when we decide to
> enable userns.
> 
Which is the same as nothing.

MEMCG being compile-time selection doesn't really mean anything.