Tycho Andersen [Fri, 19 Jan 2018 03:31:33 +0000 (03:31 +0000)]
lxc-execute: actually exit with the status of the spawned task
Now that we have things propagated through init and liblxc correctly, at
least in non-daemon mode, we can exit with the actual exit status of the
task, instead of always succeeding, which is not so helpful.
Tycho Andersen [Fri, 19 Jan 2018 03:29:05 +0000 (03:29 +0000)]
start: don't return false when the container's init exits nonzero
This seems slightly counter-intuitive, but IMO it's what we want.
Basically, ->start() should succeed if the container is spawned correctly
(similar to how golang's exec.Cmd.Start() returns nil if the thing spawns
correctly), and users can check error_num (i.e. golang's exec.Cmd.Wait())
to see how it exited.
This preserves previous behavior, which basically was that start was always
successful if the thing actually launched. Since we never kept track of
exit codes, this would always succeed too. Now that we do, it doesn't, and
this change is required.
Tycho Andersen [Fri, 19 Jan 2018 03:24:59 +0000 (03:24 +0000)]
remember the exit code from the init process
error_num seems to be trying to remember the exit code of the init process,
except that nothing actually keeps track of it anywhere. So, let's add a
field to the handler, so that we can keep track of the process' exit
status, and the propagate it to error_num in struct lxc_container so that
people can use it.
Note that this is a slight behavior change, essentially instead of making
error_num always == the return code from start, now it contains slightly
more useful information (the actual exit status). But, there is only one
internal user of error_num which I'll fix in later in the series, so IMO
this is ok.
Tycho Andersen [Fri, 19 Jan 2018 03:21:10 +0000 (03:21 +0000)]
lxc.init: correctly exit with the app's error code
Based on the comments in the code (and the have_status flag), the intent
here (and IMO, the desired behavior) should be for init.lxc to propagate
the actual exit code from the real application process up through.
Otherwise, it is swallowed and nobody can access it.
The bug being fixed here is that ret held the correct exit code, but when
it went around the loop again (to wait for other children) ret is
clobbered. Let's save the desired exit status somewhere else, so it can't
get clobbered, and we propagate things correctly.
Tycho Andersen [Fri, 19 Jan 2018 03:20:08 +0000 (03:20 +0000)]
fix lxc_error_set_and_log to match the docs
The documentation for this function says if the task was killed by a
signal, the return code will be 128+n, where n is the signal number. Let's
make that actually true.
Tycho Andersen [Fri, 19 Jan 2018 00:50:39 +0000 (00:50 +0000)]
start: don't log stop/continue for non-init processes
This non-init forwarding check should really be before all the log messages
about "init continued" or "init stopped", since they will otherwise lie
about some process that wasn't init being stopped or continued.
When we deleted cgroups for unprivileged containers we used to allocate a new
mapping and clone a new user namespace each time we delete a cgroup. This of
course meant - on a cgroup v1 system - doing this >= 10 times when all
controllers were used. Let's not to do this and only allocate and establish a
mapping once.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
When fully unprivileged users run a container that only maps their own {g,u}id
and they do not have access to setuid new{g,u}idmap binaries we will write the
idmapping directly. This however requires us to write "deny" to
/proc/[pid]/setgroups otherwise any write to /proc/[pid]/gid_map will be
denied.
On a sidenote, this patch enables fully unprivileged containers. If you now set
lxc.net.[i].type = empty no privilege whatsoever is required to run a container.
Enhances #2033.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: Felix Abecassis <fabecassis@nvidia.com> Cc: Jonathan Calmels <jcalmels@nvidia.com> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Serge Hallyn [Thu, 4 Jan 2018 03:02:53 +0000 (21:02 -0600)]
configure.ac: fix the check for static libcap
The existing check doesn't work, because when you statically
link a program against libc, any functions not called are not
included. So cap_init() which we check for is not there in
the built binary.
So instead just check whether a "gcc -lcap -static" works.
If libcap.a is not available it will fail, if it is it will
succeed.
mainloop: capture output of short-lived init procs
The handler for the signal fd will detect when the init process of a container
has exited and cause the mainloop to close. However, this can happen before the
console handlers - or any other events for that matter - are handled. So in the
case of init exiting we still need to allow for all buffered input to the
console to be handled before exiting. This allows us to capture output from
short-lived init processes.
This is conceptually equivalent to my implementation of ExecReaderToChannel()
https://github.com/lxc/lxd/blob/master/shared/util_linux.go#L527
Closes #1694.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
When set set{u,g}id() the kernel will make us undumpable. This is unnecessary
since we can guarantee that whatever is running inside the child process at
this point this is fully trusted by the parent. Making us dumpable let's users
use debuggers on the child process before the exec as well and also allows us
to open /proc/<child-pid> files in lieu of the child.
Note, that we only need to perform the prctl(PR_SET_DUMPABLE, ...) if our
effective uid on the host is not 0. If our effective uid on the host is 0 then
we will keep all capabilities in the child user namespace across set{g,u}id().
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Receive fd for LSM security module before we set{g,u}id(). The reason is that
on set{g,u}id() the kernel will a) make us undumpable and b) we will change our
effective uid. This means our effective uid will be different from the
effective uid of the process that created us which means that this processs no
longer has capabilities in our namespace including CAP_SYS_PTRACE. This means
we will not be able to read and /proc/<pid> files for the process anymore when
/proc is mounted with hidepid={1,2}. So let's get the lsm label fd before the
set{g,u}id().
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
At this point, macros such DEBUG or ERROR does not take effect because
this code is called from cgroup_ops_init(cgroup.c), which runs with
__attribute__((constructor)), before any log level is set form any tool
like lxc-start, so these messages are lost.
For now on, use the same LXC_DEBUG_CGFSNG environment variable to
control these messages.
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
This is based on raw_clone in systemd but adapted to our needs. The main reason
is that we need an implementation of fork()/clone() that does guarantee us that
no pthread_atfork() handlers are run. While clone() in glibc currently doesn't
run pthread_atfork() handlers we should be fine but there's no guarantee that
this won't be the case in the future. So let's do the syscall directly - or as
direct as we can. An additional nice feature is that we get fork() behavior,
i.e. lxc_raw_clone() returns 0 in the child and the child pid in the parent.
Our implementation tries to make sure that we cover all cases according to
kernel sources. Note that we are not interested in any arguments that could be
passed after the stack.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
When we report STOPPED to a caller and then close the command socket it is
technically possible - and I've seen this happen on the test builders - that a
container start() right after a wait() will receive ECONNREFUSED because it
called open() before we close(). So for all new state clients simply close the
command socket. This will inform all state clients that the container is
STOPPED and also prevents a race between a open()/close() on the command socket
causing a new process to get ECONNREFUSED because we haven't yet closed the
command socket.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Tycho Andersen [Fri, 8 Dec 2017 23:23:26 +0000 (23:23 +0000)]
init: don't kill(-1) if we aren't in a pid ns
...otherwise we'll kill everyone on the machine. Instead, let's explicitly
try to kill our children. Let's do a best effort against fork bombs by
disabling forking via the pids cgroup if it exists. This is best effort for
a number of reasons:
* the pids cgroup may not be available
* the container may have bind mounted /dev/null over pids.max, so the write
doesn't do anything
Prior to this patch we raced with a very short-lived init process. Essentially,
the init process could exit before we had time to record the cgroup namespace
causing the container to abort and report ABORTING to the caller when it
actually started just fine. Let's not do this.
(This uses syscall(SYS_getpid) in the the child to retrieve the pid just in case
we're on an older glibc version and we end up in the namespace sharing branch
of the actual lxc_clone() call.)
Additionally this fixes the shortlived tests. They were faulty so far and
should have actually failed because of the cgroup namespace recording race but
the ret variable used to return from the function was not correctly
initialized. This fixes it.
Furthermore, the shortlived tests used the c->error_num variable to determine
success or failure but this is actually not correct when the container is
started daemonized.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
In the case the container has a console with a valid slave pty file descriptor
we duplicate std{in,out,err} to the slave file descriptor so console logging
works correctly. When the container does not have a valid slave pty file
descriptor for its console and is started daemonized we should dup to
/dev/null.
Closes #1646.
Signed-off-by: Li Feng <lifeng68@huawei.com> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
we made std{err,in,out} a duplicate of the slave file descriptor of the console
if it existed. This meant we also duplicated all of them when we executed
application containers in the foreground even if some std{err,in,out} file
descriptor did not refer to a {p,t}ty. This blocked use cases such as:
echo foo | lxc-execute -n -- cat
which are very valid and common with application containers but less common
with system containers where we don't have to care about this. So my suggestion
is to unconditionally duplicate std{err,in,out} to the console file descriptor
if we are either running daemonized - this ensures that daemonized application
containers with a single bash shell keep on working - or when we are not
running an application container. In other cases we only duplicate those file
descriptors that actually refer to a {p,t}ty. This logic is similar to what we
do for lxc-attach already.
Refers to #1690.
Closes #2028.
Reported-by: Felix Abecassis <fabecassis@nvidia.com> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
projects / thirdparty / lxc.git / log
