Kir,
Please take a look at the following patches. They implement support for
unprivileged containers using user namespaces, and should work, modulo bugs.
v2:
* use conf_parse_ulong to simplify uid/gid parsing. We do need to provide a
default value for creation, though.
* allow 0 to be
When running with an upstream Linux kernel that supports user namespaces,
we will run the container using an unprivileged user in the system. That
can be any user, and it serves as base to a 1:1 mapping between users in
the container and users in the host.
By default, the value 10 will be
We need to pass more information to fs_create. Instead of adding arguments, it
is preferred to pass the whole vps_p structure and unfold it inside the callee.
Signed-off-by: Glauber Costa glom...@parallels.com
---
src/lib/create.c | 13 -
1 file changed, 8 insertions(+), 5
This patch allows the execution of unprivileged containers running ontop
of an upstream Linux Kernel. We will run at whatever UID is found in the
configuration file.
Signed-off-by: Glauber Costa glom...@parallels.com
---
include/types.h| 1 +
src/lib/env.c | 16 ++
If we are running upstream with user namespaces, we need to create the
container filesystem not with the ownership preserved, but reflecting the
mapping we need to apply.
The long term goal is to patch the tar utility to allow us to specify an offset
that will be applied during extraction.
In theory, we won't be able to run if our private area is not owned by
ourselves. We could, if it have very wide open security permissions, but we
should never set up a container like that.
Aside from a basic sanity check, this is intended to catch problems for the few
people who may have
It is a valid use case to run a container with host uid and gid different
than the default. This patch provides and documents a way to do so.
Signed-off-by: Glauber Costa glom...@parallels.com
---
man/vzctl.8.in | 14 ++
src/vzctl-actions.c | 2 ++
src/vzctl.c | 1 +
3
