Serge Hallyn [Tue, 8 Mar 2016 03:10:58 +0000 (19:10 -0800)]
prevent containers from reading /sys/kernel/debug
Unprivileged containers cannot read it anyway, but also prevent root
owned containers from doing so. Sadly upstart's mountall won't run
if we try to prevent it from being mounted at all.
Serge Hallyn [Mon, 7 Mar 2016 19:16:43 +0000 (11:16 -0800)]
cgfsng - remove the code checking whether devices cgroup lines are already done
We may need to revert this, but I *think* we no longer need this
with default configs. The idea iirc was that if caller cannot
write to devices.allow (i.e. is in a user namespace), then ignore
permission failures if the cgroups are already sufficiently setup.
Serge Hallyn [Thu, 3 Mar 2016 18:31:23 +0000 (10:31 -0800)]
cgfsng: next generation filesystem-backed cgroup implementation
This makes simplifying assumptions: all usable cgroups must be
mounted under /sys/fs/cgroup/controller or /sys/fs/cgroup/contr1,contr2.
Currently this will only work with cgroup namespaces, because
lxc.mount.auto = cgroup is not implemented. So cgfsng_ops_init()
returns NULL if cgroup namespaces are not enabled.
lxc-attach -n a -- sh -c 'echo ERR >&2' > /dev/null
There seems to be no easy way to discern when we need to write to stderr
instead of stdout when we receive an event on the master fd of an allocated
pty. So we're using a "trick"/"hack". We write to STDOUT_FILENO if it refers to
a pty. If STDOUT_FILENO does not refer to a pty we check whether STDERR_FILENO
refers to a pty and if so write to it.
Signed-off-by: Christian Brauner <christian.brauner@mailbox.org>
Execute script lxc-devsetup also with sysvinit and upstart.
* This script sets /dev/.lxc which is needed for autodev containers.
* Previously was only executed with systemd. Execute it also with
the other init systems (sysvinit and upstart)
Signed-off-by: Carlos Alberto Lopez Perez <clopez@igalia.com>
Serge Hallyn [Thu, 3 Mar 2016 00:11:14 +0000 (16:11 -0800)]
cgfs: don't try to remove cgroups we haven't created
info_ptr->created_paths_count can be 0, so don't blindly dereference
info_ptr->created_paths[ created_paths_count - 1]. Apparently we never
used to have 0 at the cleanup_name_on_this_level before, but now that
we can fail with -eperm and not just -eexist, we do.
lxc should not reboot the container when lxc.hook.post-stop fails. It should
simply shutdown. This makes the behavior of lxc.hook.post-stop and
lxc.hook.pre-start consistent. When lxc.hook.pre-start fails, the container
does not start.
Signed-off-by: Christian Brauner <christian.brauner@mailbox.org>
lxc-attach: always allocate current controlling pty
lxc-attach uses lxc_console_create() to allocate a pty on the host.
lxc_console_create() in turn calls lxc_console_peer_default() which either
makes the current controlling pty our controlling pty for the container, or
uses whatever the user gave us (e.g. /dev/tty2 etc.). For lxc-attach we always
want the current controlling pty to be used. This commit ensures that we're in
fact always using the current controlling pty. The commit also fixes a segfault
when the user specified lxc.console.path = none.
Signed-off-by: Christian Brauner <christian.brauner@mailbox.org>
Serge Hallyn [Fri, 26 Feb 2016 20:03:09 +0000 (20:03 +0000)]
fix cgfs failure for unpriv users
Cgmanager was taught awhile ago that only some cgroup controllers are
crucial. Teach cgfs the same thing.
This patch needs improvement, but will fix failure of lxc without cgmanager
for unprivileged users for now. In particular, needed improvements include:
1. the check for crucial subsystems needs to include lxc.use
2. we should keep a list of the actually used subsystems so we don't keep
trying to chmod and enter after create has found we couldn't use a particular
subsystem
This fixes unprivileged lxc use. It does not appear to suffice to fix
nested unprivilegd lxd usage.
Serge Hallyn [Thu, 25 Feb 2016 19:01:12 +0000 (11:01 -0800)]
cgfs: make sure we use valid cgroup mountpoints
If lxcfs starts before cgroup-lite, then the first cgroup mountpoints in
/proc/self/mountinfo are /run/lxcfs/*. Unprivileged users cannot access
these. So privileged containers are ok, and unprivileged containers are ok
since they won't cache those to begin with. But unprivileged root-owned
containers cache /run/lxcfs/* and then try to use them.
So when doing cgroup automounting check whether the mountpoints we have
stored are accessible, and if not look for a new one to use.
Serge Hallyn [Thu, 25 Feb 2016 01:00:35 +0000 (17:00 -0800)]
cgfs: do not automount if cgroup namespaces are supported
In that case containers will be able to mount cgroup filesystems
for themselves as they do on a host.
This fixes inability to start systemd based containers on cgns-enabled
kernels with cgmanager not running.
I've tested debian jessie, busybox, ubuntu trusty and xenial, all of
which booted ok. However if there are some setups which require
premounted cgroupfs (i.e. they don't mount if they detect being in
a container), this may cause trouble.
- lxc-clone and lxc-start-ephemeral are marked deprecated. We add a
--enable-deprecated flag to configure.ac allowing us to enable these
deprecated executables
- update tests to use lxc-copy instead of lxc-clone
Signed-off-by: Christian Brauner <christian.brauner@mailbox.org>
- add note to lxc-clone manpage that it is superseded by lxc-copy
- add note to lxc-start-ephemeral manpage that it is superseded by lxc-copy
- fix typo in lxc-attach manpage
- fix some of my comments in lxc_ls.c
Signed-off-by: Christian Brauner <christian.brauner@mailbox.org>
- explain rationale behind allocation of pty
- briefly explain how a pty is allocated
- add a short note that describes the changed behavior for lxc-attach when the
user is not placed in a writeable cgroup at login
Signed-off-by: Christian Brauner <christian.brauner@mailbox.org>
- The code required to prepare an fd to act as a login tty is shared among
pty_on_host_callback() and fork_pty(). This implements login_pty(), a
minimalistic login_tty() clone, to avoid code redundancy.
- Give pty_in_container() a slightly extended comment.
Signed-off-by: Christian Brauner <christian.brauner@mailbox.org>