lxc-test-{unpriv,usernic.in}: make sure to chgrp as well
These tests are failing on new kernels because the container root is
not privileged over the directories, since privilege no requires
the group being mapped into the container.
veth.pair is ignore for unprivileged containers as allowing an
unprivileged user to set a specific device name would allow them to
trigger actions in tools like NetworkManager or other uevent based
handlers that may react based on specific names or prefixes being used.
centos template: prevent mingetty from calling vhangup(2)
When using unprivileged containers, tty fails because of vhangup. Adding
--nohangup to nimgetty, it fixes the issue. This is the same problem
occurred for oracle template, commit 2e83f7201c5d402478b9849f0a85c62d5b9f1589
confile: sanity-check netdev->type before setting netdev->priv elements
The netdev->priv is shared for the netdev types. A bad config file
could mix configuration for different types, resulting in a bad
netdev->priv when starting or even destroying a container. So sanity
check the netdev->type before setting a netdev->priv element.
This should fix https://github.com/lxc/lxc/issues/254
Fix incorrect timeout handling of do_reboot_and_check()
Currently do_reboot_and_check() is decreasing timeout variable even if
it is set to -1, so running 'lxc-stop --reboot --timeout=-1 ...' will
exits immediately at end of second iteration of loop, without waiting
container reboot.
Also, there is no need to call gettimeofday if timeout is set to -1, so
these statements should be evaluated only when timeout is enabled.
Signed-off-by: Yuto KAWAMURA(kawamuray) <kawamuray.dadada@gmail.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
- Mounting cgroup:mixed prevents systemd inside the container from
moving its children out of the cgroups lxc setup. This ensure the
limits setup in the configuration or with lxc-cgroup are effective.
- Update for the OL7 channel name that will be used on
public-yum.oracle.com.
chown_mapped_root: don't try chgrp if we don't own the file
New kernels require that to have privilege over a file, your
userns must have the old and new groups mapped into your userns.
So if a file is owned by our uid but another groupid, then we
have to chgrp the file to our primary group before we can try
(in a new user namespace) to chgrp the file to a group id in the
namespace.
But in some cases (when cloning) the file may already be mapped
into the container. Now we cannot chgrp the file to our own
primary group - and we don't have to.
So detect that case. Only try to chgrp the file to our primary
group if the file is owned by our euid (i.e. not by the container)
and the owning group is not already mapped into the container by
default.
With this patch, I'm again able to both create and clone containers
with no errors again.
TAMUKI Shoichi [Sat, 28 Jun 2014 09:39:54 +0000 (18:39 +0900)]
Fix to work lxc-destroy with unprivileged containers on recent kernel
Change idmap_add_id() to add both ID_TYPE_UID and ID_TYPE_GID entries
to an existing lxc_conf, not just an ID_TYPE_UID entry, so as to work
lxc-destroy with unprivileged containers on recent kernel.
TAMUKI Shoichi [Fri, 27 Jun 2014 08:29:01 +0000 (17:29 +0900)]
Fix to work lxc-start with unprivileged containers on recent kernel
Change chown_mapped_root() to map in both the root uid and gid, not
just the uid, so as to work lxc-start with unprivileged containers on
recent kernel.
Serge Hallyn [Thu, 26 Jun 2014 21:44:46 +0000 (16:44 -0500)]
cgmanager: have cgm_set and cgm_get use absolute path when possible
This allows users to get/set cgroup settings when logged into a different
session than that from which they started the container.
There is no cgmanager command to do an _abs variant of cgmanager_get_value
and cgmanager_set_value. So we fork off a new task, which enters the
parent cgroup of the started container, then can get/set the value from
there. The reason not to go straight into the container's cgroup is that
if we are freezing the container, or the container is already frozen, we'll
freeze as well :) The reason to fork off a new task is that if we are
in a cgroup which is set to remove-on-empty, we may not be able to return
to our original cgroup after making the change.
This should fix https://github.com/lxc/lxc/issues/246
lxc-archlinux.in: update securetty when lxc.devttydir is set
Update container's /etc/securetty to allow console logins when lxc.devttydir is not empty.
Also use config entries provided by shared and common configuration files.
Signed-off-by: Alexander Vladimirov <alexander.idkfa.vladimirov@gmail.com> Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Stéphane Graber [Fri, 20 Jun 2014 21:20:06 +0000 (17:20 -0400)]
Reduce duplication in new style configs
This is a rather massive cleanup of config/templates/*
As new templates were added, I've noticed that we pretty much all share
the tty/pts configs, some capabilities being dropped and most of the
cgroup configuration. All the userns configs were also almost identical.
As a result, this change introduces two new files:
- common.conf.in
- userns.conf.in
Each is included by the relevant <template>.<type>.conf.in templates,
this means that the individual per-template configs are now overlays on
top of the default config.
Once we see a specific key becoming popular, we ought to check whether
it should also be applied to the other templates and if more than 50% of
the templates have it set to the same value, that value ought to be
moved to the master config file and then overriden for the templates
that do not use it.
This change while pretty big and scary, shouldn't be very visible from a
user point of view, the actual changes can be summarized as:
- Extend clonehostname to work with Debian based distros and use it for
all containers.
- lxc.pivotdir is now set to lxc_putold for all templates, this means
that instead of using /mnt in the container, lxc will create and use
/lxc_putold instead. The reason for this is to avoid failures when the
user bind-mounts something else on top of /mnt.
- Some minor cgroup limit changes, the main one I remember is
/dev/console now being writable by all of the redhat based containers.
The rest of the set should be identical with additions in the per-distro
ones.
- Drop binfmtmisc and efivars bind-mounts for non-mountall based
unpriivileged containers as I assumed they got those from copy/paste
from Ubuntu and not because they actually need those entries. (If I'm
wrong, we probably should move those to userns.conf then).
Additional investigation and changes to reduce the config delta between
distros would be appreciated. In practice, I only expect lxc.cap.drop
and lxc.mount.entry to really vary between distros (depending on the
init system, the rest should be mostly common.
Diff from the RFC:
- Add archlinux to the mix
- Drop /etc/hostname from the clone hook
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Prevent write_config from corrupting container config
write_config doesn't check the value sig_name function returns,
this causes write_config to produce corrupted container config when
using non-predefined signal names.
Signed-off-by: Alexander Vladimirov <alexander.idkfa.vladimirov@gmail.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Update Arch Linux template and add common configuration files
Move common container configuration entries into template config.
Remove unnecessary service symlinking and configuration entries, as well as
guest configs and other redundant configuration, fix minor script bugs.
Clean up template command line, add -d option to allow disabling services.
Also enable getty's on all configured ttys to allow logins via lxc-console,
set lxc.tty value corresponding to default Arch /etc/securetty configuration.
This patch simplifies Arch Linux template a bit, while fixing some
longstanding issues. It also provides common configuration based on
files provided for Fedora templates.
Signed-off-by: Alexander Vladimirov <alexander.idkfa.vladimirov@gmail.com> Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Serge Hallyn [Fri, 20 Jun 2014 20:40:42 +0000 (15:40 -0500)]
ubuntu containers: use a seccomp filter by default (v2)
Blacklist module loading, kexec, and open_by_handle_at (the cause of the
not-docker-specific dockerinit mounts namespace escape).
This should be applied to all arches, but iiuc stgraber will be doing
some reworking of the commonizations which will simplify that, so I'm
not doing it here.
Serge Hallyn [Fri, 20 Jun 2014 19:58:41 +0000 (14:58 -0500)]
seccomp: fix 32-bit rules
When calling seccomp_rule_add(), you must pass the native syscall number
even if the context is a 32-bit context. So use resolve_name rather
than resolve_name_arch.
Enhance the check of /proc/self/status for Seccomp: so that we do not
enable seccomp policies if seccomp is not built into the kernel. This
is needed before we can enable by-default seccomp policies (which we
want to do next)
Fix wrong return value check from seccomp_arch_exist, and remove
needless abstraction in arch handling.
Serge Hallyn [Thu, 19 Jun 2014 20:52:34 +0000 (20:52 +0000)]
seccomp: support 'all' arch sections (plus bugfixes)
seccomp_ctx is already a void*, so don't use 'scmp_filter_ctx *'
Separately track the native arch from the arch a rule is aimed at.
Clearly ignore irrelevant architectures (i.e. arm rules on x86)
Don't try to load seccomp (and don't fail) if we are already
seccomp-confined. Otherwise nested containers fail.
Make it clear that the extra seccomp ctx is only for compat calls
on 64-bit arch. (This will be extended to arm64 when libseccomp
supports it). Power may will complicate this (if ever it is supported)
and require a new rethink and rewrite.
NOTE - currently when starting a 32-bit container on 64-bit host,
rules pertaining to 32-bit syscalls (as opposed to once which have
the same syscall #) appear to be ignored. I can reproduce that without
lxc, so either there is a bug in seccomp or a fundamental
misunderstanding in how I"m merging the contexts.
Rereading the seccomp_rule_add manpage suggests that keeping the seccond
seccomp context may not be necessary, but this is not something I care
to test right now. If it's true, then the code could be simplified, and
it may solve my concerns about power.
With this patch I'm able to start nested containers (with seccomp
policies defined) including 32-bit and 32-bit-in-64-bit.
[ this patch does not yet add the default seccomp policy ]
Dwight Engen [Thu, 19 Jun 2014 21:58:11 +0000 (17:58 -0400)]
allow lxc.cap.keep = none
Commit 1fb86a7c introduced a way to drop capabilities without having to
specify them all explicitly. Unfortunately, there is no way to drop them
all, as just specifying an empty keep list, ie:
lxc.cap.keep =
clears the keep list, causing no capabilities to be dropped.
This change allows a special value "none" to be given, which will clear
all keep capabilities parsed up to this point. If the last parsed value
is none, all capabilities will be dropped.
Signed-off-by: Dwight Engen <dwight.engen@oracle.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Dwight Engen [Thu, 19 Jun 2014 13:01:26 +0000 (09:01 -0400)]
don't force dropping capabilities in lxc-init
Commit 0af683cf added clearing of capabilities to lxc-init, but only
after lxc_setup_fs() was done, likely so that the mounting done in
that routine wouldn't fail.
However, in my testing lxc_caps_reset() wasn't really effective
anyway since it did not clear the bounding set. Adding prctl
PR_CAPBSET_DROP in a loop from 0 to CAP_LAST_CAP would fix this, but I
don't think its necessary to forcefully clear all capabilities since
users can now specify lxc.cap.keep = none to drop all capabilities.
Signed-off-by: Dwight Engen <dwight.engen@oracle.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Stéphane Graber [Wed, 18 Jun 2014 21:33:10 +0000 (17:33 -0400)]
lxc-download: Bump compat to 2 after OpenSUSE
OpenSUSE is now ready for the download template in the master branch,
however it's not going to be compatible with older LXC as they lack the
needed config files, so bump the compat level to 2 to indicate that the
current lxc-download can deal with the current OpenSUSE containers.
Serge Hallyn [Tue, 27 May 2014 21:24:06 +0000 (16:24 -0500)]
snapshots: move snapshot directory
Originally we kept snapshots under /var/lib/lxcsnaps. If a
separate btrfs is mounted at /var/lib/lxc, then we can't
make btrfs snapshots under /var/lib/lxcsnaps.
This patch moves the default directory to /var/lib/lxc/c/snaps.
If /var/lib/lxcsnaps already exists, then we continue to use that.
add c->destroy_with_snapshots() and c->snapshot_destroy_all()
API methods. c->snashot_destroy_all() can be triggered from
lxc-snapshot using '-d ALL'. There is no command to call
c->destroy_with_snapshots(c) as of yet.
lxclock: use ".$lxcname" for container lock files
that way we can use /run/lock/lxc/$lxcpath/$lxcname/snaps as a
directory when locking snapshots without having to worry about
/run/lock//lxc/$lxcpath/$lxcname being a file.
destroy: split off a container_destroy
container_destroy() doesn't check for snapshots, so snapshot_rename can
use it. api_destroy() now does check for snapshots (previously it only
checked for fs - i.e. overlayfs/aufs - snapshots).
Add destroy to the manpage, as it was previously undocumented.
Serge Hallyn [Thu, 12 Jun 2014 13:46:37 +0000 (13:46 +0000)]
Store alien config lines
Any config lines not starting with 'lxc.*' are ignored by lxc. That
can be useful for third party tools, however lxc-clone does not copy such
lines.
Fix that by tracking such lines in our unexpanded config file and
printing them out at write_config(). Note two possible shortcomings here:
1. we always print out all includes followed by all aliens. They are
not kept in order, nor ordered with respect to lxc.* lines.
2. we're still not storing comments. these could easily be added to
the alien lines, but i chose not to in particular since comments are
usually associated with other lines, so destroying the order would
destroy their value. I could be wrong about that, and if I am it's
a trivial fix.
Serge Hallyn [Thu, 12 Jun 2014 14:24:38 +0000 (14:24 +0000)]
Add a unexpanded lxc_conf
Currently when a container's configuration file has lxc.includes,
any future write_config() will expand the lxc.includes. This
affects container clones (and snapshots) as well as users of the
API who make an update and then c.save_config().
To fix this, separately track the expanded and unexpanded lxc_conf. The
unexpanded conf does not contain values read from lxc.includes. The
expanded conf does. Lxc functions mainly need the expanded conf to
figure out how to configure the container. The unexpanded conf is used
at write_config().
Updated lxc-opensuse for common configuration changes.
Updated the lxc-opensuse template for the changes for the common
configuration used by the download template. Changed the default
network mode in the container to dhcp.
Signed-off-by: Michael H. Warfield <mhw@WittsEnd.com> Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Serge Hallyn [Wed, 18 Jun 2014 19:36:37 +0000 (19:36 +0000)]
seccomp: warn but continue on unresolvable syscalls
If a syscall is listed which is not resolvable, continue. This allows
us to keep a more complete list of syscalls in a global seccomp policy
without having to worry about older kernels not supporting the newer
syscalls.
Stéphane Graber [Fri, 13 Jun 2014 21:45:26 +0000 (17:45 -0400)]
tests: Avoid the download template when possible
The use of the download template with an hardcoded --arch=amd64 in aa.c
was causing test failures on any platform incapable of running amd64
binaries.
This wasn't noticed in the CI environment as we run the tests within
containers on an amd64 kernel but this caused failures on the Ubuntu CI
environment.
Instead, let's use the busybox template, tweaking the configuration when
needed to match the needs of the testcase.
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Stéphane Graber [Mon, 9 Jun 2014 21:13:56 +0000 (17:13 -0400)]
tests: Wait 5s for init to respond in lxc-test-autostart
lxc-test-autostart occasionaly fails at the restart test in the CI
environment. Looking at the current test case, the most obvious race
there is if lxc-wait exists succesfuly immediately after LXC marked the
container RUNNING (init spawned) but before init had a chance to setup
the signal handlers.
To avoid this potential race period, let's add a 5s delay between the
tests to give a chance for init to finish starting up.
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Stéphane Graber [Wed, 4 Jun 2014 18:05:25 +0000 (14:05 -0400)]
Try to be more helpful on container startup failure
This hides some of the confusing "command X failed to receive response"
why are usually caused by another more understandable error.
On failure to start() from lxc-start, a new error message is displayed,
suggesting the user sets logfile and loglevel and if using -d, restarts
the container in the foreground instead.
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
*) The -g / --groups option is multiple cummulative entry.
This may be mixed freely with the previous comma separated
group list convention. Groups are processed in the
order they first appear in the aggregated group list.
*) The NULL group may be specified in the group list using either a
leading comma, a trailing comma, or an embedded comma.
*) Booting proceeds in order of the groups specified on the command line
then ordered by lxc.start.order and name collalating sequence.
*) Default host bootup is now specified as "-g onboot," meaning that first
the "onboot" group is booted and then any remaining enabled
containers in the NULL group are booted.
*) Adds documentation to lxc-autostart for -g processing order and
combinations.
*) Parameterizes bootgroups, options, and shutdown delay in init scripts
and services.
*) Update the various init scripts to use lxc-autostart in a similar way.
Reported-by: CDR <venefax@gmail.com> Signed-off-by: Dwight Engen <dwight.engen@oracle.com> Signed-off-by: Michael H. Warfield <mhw@WittsEnd.com> Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Serge Hallyn [Tue, 3 Jun 2014 03:04:12 +0000 (22:04 -0500)]
configure.ac: don't let -lcgmanager end up in LIBS
AC_SEARCH_LIBS always places the library being queried into LIBS. We
don't want that - we were only checking whether a function is
available. Not everything (notably not init.lxc.static) needs to
link against -lcgmanager.
Serge Hallyn [Tue, 3 Jun 2014 03:03:58 +0000 (22:03 -0500)]
execute: don't bind mount init.lxc.static if lxc-init is in the container
Move choose_init into utils.c so we can re-use it. Make it and on_path
accept an optional rootfs argument to prepend to the paths when checking
whether the file exists.
Serge Hallyn [Thu, 22 May 2014 20:49:15 +0000 (15:49 -0500)]
Specially handle block device rootfs
It is not possible to mount a block device from a non-init user namespace.
Therefore if root on the host is starting a container with a uid
mapping, and the rootfs is a block device, then mount the rootfs before
we spawn the container init task.
This addresses https://github.com/lxc/lxc/issues/221
Serge Hallyn [Thu, 22 May 2014 21:53:40 +0000 (16:53 -0500)]
attach: get personality through get_config command
Newer kernels optionally disallow reading /proc/$$/personality by
non-root users. We can get the personality through the lxc command
interface, so do so.
Also try to be more consistent about personality being a signed long.
We had it as int, unsigned long, signed long throughout the code.
Serge Hallyn [Tue, 20 May 2014 16:47:17 +0000 (11:47 -0500)]
cgmanager: slow down there (don't always grab abs cgroup path)
When I converted attach and enter to using move_pid_abs, these needed
to use the new get_pid_cgroup_abs method to get an absolute path. But
for some inexplicable reason I also converted the functions which get
and set cgroup properties to use the absolute paths. These are simply
not compatible with the cgmanager set_value and get_value methods.
This breaks for instance lxc-test-cgpath.
So undo that. With this patch lxc-test-cgpath, lxc-test-autotest,
and lxc-test-concurrent once again pass in a nested container.