Re: [PATCH 0/9] Multiple devpts instances

[Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org>]

Serge E. Hallyn wrote:
> Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
>   
>> Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> writes:
>>
>>     
>>> But if I am able to create a new instance of devpts for a container and modify
>>> the configuration of another devpts from this container, is it acceptable ? Can
>>> we convince people to use the containers for security and have anybody able to
>>> make a pty starvation from one container to another ?
>>>       
>> I hardly how that is significant.  Anyone can allocate the rest of the possible
>> pty's today.  The situation does not get worse with devpts.
>>
>> If you want security and permission arguments get with Serge and finish
>> the uid namespace.  The you will have a user that looks like root but
>> does not have permissions to do most things.
>>     
>
> Right, and in particular the way it would partially solve this issue is
> that the procsys limit file would be owned by root in the initial uid
> namespace, so root in a child container would not be able to write to
> it.
>
> Defining a new mount option to set a per-sb limit seems useful though,
> as I could easily see wanting to limit containers (on a 1000-container
> system) to 3 ptys each for instance.
>   

Yep,  I changed my mind, I think Eric and HPA are right. devpts is a 
file system and not a namespace even if the result is the same. That 
makes sense to keep a global sysctl for the root container and handle 
security problem with user namespace and mount option.

>>> If it is too much complicated to handle one value per new devpts instance, IMHO
>>> /proc/sys/kernel/pty/max should be, at least, read-only for the new instance, no?
>>>       
>> No.  Either we add a pty_max value to the filesystem like we did with ptmx
>> or we forget it.
>>     
>
> -serge
>
>
>