Quoting Eric W. Biederman (ebied...@xmission.com):
Daniel Lezcano daniel.lezc...@free.fr 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
Serge E. Hallyn wrote:
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
Serge E. Hallyn wrote:
Quoting Eric W. Biederman (ebied...@xmission.com):
Daniel Lezcano daniel.lezc...@free.fr 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
Daniel Lezcano wrote:
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.
H. Peter Anvin h...@zytor.com writes:
Serge E. Hallyn wrote:
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
suka...@linux.vnet.ibm.com wrote:
Enable multiple instances of devpts filesystem so each container can allocate
ptys independently.
Hi suka,
It looks like the /proc/sys/kernel/pty/max and nr are not virtualized.
Modifying in the container the max pty, that impacts the init_pty.
Same as nr
Daniel Lezcano wrote:
suka...@linux.vnet.ibm.com wrote:
Enable multiple instances of devpts filesystem so each container can
allocate
ptys independently.
Hi suka,
It looks like the /proc/sys/kernel/pty/max and nr are not virtualized.
Modifying in the container the max pty, that
H. Peter Anvin wrote:
Daniel Lezcano wrote:
suka...@linux.vnet.ibm.com wrote:
Enable multiple instances of devpts filesystem so each container can
allocate
ptys independently.
Hi suka,
It looks like the /proc/sys/kernel/pty/max and nr are not virtualized.
Modifying
Daniel Lezcano wrote:
Resource limit partitioning is a much bigger and orthogonal problem.
In this case we don't have the pty allocated independently, no ?
I mean one container can allocate 4095 pty, making a pty starvation for
others containers. Or imagine I am a vilain and I want to
H. Peter Anvin h...@zytor.com writes:
Daniel Lezcano wrote:
Resource limit partitioning is a much bigger and orthogonal problem.
In this case we don't have the pty allocated independently, no ?
I mean one container can allocate 4095 pty, making a pty starvation for
others
containers.
H. Peter Anvin wrote:
Daniel Lezcano wrote:
Resource limit partitioning is a much bigger and orthogonal problem.
In this case we don't have the pty allocated independently, no ?
I mean one container can allocate 4095 pty, making a pty starvation
for others containers. Or imagine I am a
Daniel Lezcano daniel.lezc...@free.fr 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
Eric W. Biederman wrote:
Really. You have the same classes of issues with ANY allocatable
resource in the system. Period. Furthermore, there are quite a few
applications which want one and not the other. Trying to entangle
them is broken.
Peter they are entangled issues because the
13 matches
Mail list logo
