We need to have lxc_attach() distinguish between a caller specifying specific
namespaces to attach to and a caller not requesting specific namespaces. The
latter is taken by lxc_attach() to mean that all namespaces will be attached.
This also needs to include all inherited namespaces.
Closes#1890.
Closes#1897.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
The configure checks for these use AC_CHECK_DECLS, which define the symbol
to 0 if not available - So adjust the code to match. From the autoconf
manual:
https://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/Generic-Declarations.html)
For each of the symbols (comma-separated list), define HAVE_DECL_symbol (in
all capitals) to ‘1’ if symbol is declared, otherwise to ‘0’.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Implement inheriting user namespaces.
- When inheriting user namespaces make sure to not try and map ids again. The
kernel will not allow you to do this.
- Change clone() logic:
1. If we inherit no namespaces simply call lxc_clone().
2. If we inherit any namespaces call lxc_fork_attach_clone(). Here's why:
- Causes one syscall (fork()) instead of two syscalls (setns() to
inherited namespace and setns() back to parent namespace) to be
performed.
- Allows us to get rid of a bunch of variables and helper functions/code.
- Sharing a user namespaces requires us to setns() to the inherited user
namespace but the kernel does not allow reattaching to a parent user
namespace. So the old logic made user namespace inheritance impossible.
By using the lxc_fork_attach_clone() model we can simply setns() to the
inherited user namespace in the fork()ed child and be done with it.
The only thing we need to do is to specify CLONE_PARENT when calling
clone() in lxc_fork_attach_clone() so that we can wait on the child.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Brings the number of open fds in the monitor process for a standard container
without ttys down to 17.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
There's no obvious need to strdup() the name of the container in the handler.
We can simply make this a pointer to the memory allocated in
lxc_container_new().
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Some toolchains which are not bionic like uclibc does not support
prlimit or prlimit64. In this case, return an error.
Moreover, if prlimit64 is available, use lxc implementation of prlimit.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
In case cgroup namespaces are supported but we do not have CAP_SYS_ADMIN we
need to mount cgroups for the container. This patch enables both privileged and
unprivileged containers without CAP_SYS_ADMIN.
Closes#1737.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
When attaching to a container's namespaces we did not handle the case where we
inherited namespaces correctly. In essence, liblxc on start records the
namespaces the container was created with in the handler. But it only records
the clone flags that were passed to clone() and doesn't record the namespaces
we e.g. inherited from other containers. This means that attach only ever
attached to the clone flags. But this is only correct if all other namespaces
not recorded in the handler refer to the namespaces of the caller. However,
this need not be the case if the container has inherited namespaces from
another container. To handle this case we need to check whether caller and
container are in the same namespace. If they are, we know that things are all
good. If they aren't then we need to attach to these namespaces as well.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
This avoids the dance of updating the list of valid releases every time
Debian makes a new release.
It also fixes the following bug: even though lxc-debian will default to
creating containers of the latest stable by querying the archive, it
won't allow you to explicitly request `stable` because the current list
of valid releases don't include it.
Last, but not least, avoid hitting the mirror in the case the desired
release is one of the ones we know will always be there, i.e. stable,
testing, sid, and unstable.
Signed-off-by: Antonio Terceiro <terceiro@debian.org>
Being able to create `testing` containers, regardless of what's the name
of the next stable, is useful in several contexts, included but not
limited to testing purposes. i.e. one won't need to explicitly switch to
`bullseye` once `buster` is released to be able to continue tracking
`testing`. While we are at it, let's also enable `unstable`, which is
exactly the same as `sid`, but there is no reason for not being able to.
Signed-off-by: Antonio Terceiro <terceiro@debian.org>
