lxc_console dereferences C, so we should check that it is not null and fail if
it is.
Reported-by: Coverity
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
1. don't cast to long
2. check overflow before addition
v2: just remove the cast, don't change the type of the variables
Reported-by: Coverity
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
These are two fixes for long, long-standing bugs.
1. When we stop a container from the lxc_cmd stop handler, we kill its
init task, then we unfreeze the container to make sure it receives the
signal. When that unfreeze succeeds, we were immediately returning 0,
without sending a response to the invoker.
2. lxc_cmd returns the length of the field received. In the case of
an lxc_cmd_stop this is 16. But a comment claims we expect no response,
only a 0. In fact the handler does send a response, which may or may
not include an error. So don't call an error just because we got back a
response.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Since attach asks the restore process what the clone flags were, if we forgot
to set them then the attach command ran in the hosts namespaces instead of the
containers, which is a Very Bad Thing :). Instead, we remember to set the clone
flags in the restore process' handler, so that we report them correctly to any
attach processes who ask.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
$container_rootfs may not be used so 'sed' will try to patch
"/etc/init/tty.conf". It must not be correct.
Signed-off-by: Teruo Oshida <teruo.oshida@miraclelinux.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
It is impolite to print stuff to stderror owned by other people, and they might
miss it anyway since it's not in the normal log location.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Instead, the parent always writes a status to the pipe.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Previously, lxcapi_restore used the calling process as the lxc monitor process
(and just never returned), requiring users to fork before calling it. This, of
course, would cause problems for things like LXD, which can't fork.
Now, restore() forks the monitor as a child of the process that calls it. Users
who want to daemonize the restore process need to fork themselves.
lxc-checkpoint has been updated to reflect this behavior change.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
If an unprivileged ephemeral container is started as follows,
lxc-start-ephemeral -o trusty -n test_ephemeral
Then an empty directory remains upon exit from the container,
~/.local/share/lxc/test_ephemeral/tmpfs/delta0
(The tmpfs filesystem is successfully unmounted, but we seem to lack
permission to delete the delta0 directory).
This issue arose following commits 4799a1e and dd2271e .
The following patch resolves the issue. It has been tested on ubuntu
14.04 with the lxc-daily ppa.
Since gmail screws up the formatting of the patch via line-wrapping
etc, please copy the patch from the issue-tracker rather than from
this email.
Signed-off by: Oleg Freedholm <overlayfs@gmail.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
CRIU needs to be told when something is bind mounted into the container from
the outside as cgmanager's socket is.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
One of the 'features' of overlayfs is that depending on whether a file
is on the upper or lower dir you get back a different device from stat.
That breaks our lxc_rmdir_onedev.
So at lxc_rmdir_ondev check the device of the directory being deleted.
If it is overlayfs, then skip the device check.
Note this is unrelated to overlayfs snapshots - in those cases when you
delete a container, /var/lib/lxc/$container/ does not actually have an
overlayfs under it. Rather, to reproduce this you would
sudo mkdir /opt/{lower,upper,workdir}
sudo mount -t overlayfs -o lower=/opt/lower,upper=/opt/upper,workdir=/opt/workdir \
lxc /var/lib/lxc
sudo lxc-create -t download -n c1 -- -d ubuntu -r trusty -a amd64
sudo lxc-destroy -n c1
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Tested-by: Marko Ratkaj <marko.ratkaj@sartura.hr>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
This is only called at startup so it wasn't a big leak, but it is a leak.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Currently if we are in /user.slice/user-1000.slice/session-c2.scope,
and we start an unprivileged container t1, it will be in cgroup
3:memory:/user.slice/user-1000.slice/session-c2.scope/t1. If
we then do a 'lxc-cgroup -n t1 freezer.tasks', cgm_get will
first switch to 3:memory:/user.slice/user-1000.slice/session-c2.scope
then look up 't1's values. The reasons for this are
1. cgmanager get_value is relative to your own cgroup, so we need
to be sure to be in t1's cgroup or an ancestor
2. we don't want to be in the container's cgroup bc it might freeze us.
But in Ubuntu 15.04 it was decided that
3:memory:/user.slice/user-1000.slice/session-c2.scope/tasks should
not be writeable by the user, making this fail.
Therefore put all unprivileged cgroups under "lxc/%n". That way
the "lxc" cgroup should always be owned by the user so that he can
enter.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
The logging code uses a global log_fd and log_level to direct
logging (ERROR(), etc). While the container configuration file allows
for lxc.loglevel and lxc.logfile, those are only used at configuration
file read time to set the global variables. This works ok in the
lxc front-end programs, but becomes a problem with threaded API users.
The simplest solution would be to not allow per-container configuration
files, but it'd be nice to avoid that.
Passing a logfd or lxc_conf into every ERROR/INFO/etc call is "possible",
but would be a huge complication as there are many functions, including
struct member functions and callbacks, which don't have that info and
would need to get it from somewhere.
So the approach I'm taking here is to say that all real container work
is done inside api calls, and therefore the API calls themselves can
set a thread-local variable indicating which log info to use. If
unset, then use the global values. The lxc-* programs, when called
with a '-o logfile' argument, set a global variable to indicate that
the user-specified value should be used.
In this patch:
If the lxc container configuration specifies a loglevel/logfile, only
set the lxc_config's logfd and loglevel according to those, not the
global values.
Each API call is wrapped to set/unset the current_config. (The few
exceptions are calls which do not result in any log actions)
Update logfile appender to use the logfile specified in lxc_conf if (a)
current_config is set and (b) the lxc-* command did not override it.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
This patch enables seccomp support for LXC containers running on PowerPC
architectures. It is based on the latest PowerPC support added to libseccomp, on
the working-ppc64 branch [1].
Libseccomp has been tested on ppc, ppc64 and ppc64le architectures. LXC with
seccomp support has been tested on ppc and ppc64 architectures, using the
default seccomp policy example files delivered with the LXC package.
[1] https://github.com/seccomp/libseccomp/commits/working-ppc64
v2:
- add #ifdefs in get_new_ctx to fix builds on systems not having SCMP_ARCH_PPC*
defined
Signed-off-by: Bogdan Purcareata <bogdan.purcareata@freescale.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Fix a typo in the getopt call, should be auth-key not auth_key.
Also provide the argument to cat, so the script doesn't hang waiting
on stdin.
Closes#379
Signed-off-by: Erik Mackdanz <erikmack@gmail.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Also fix some indentation and improve translation.
Update for commit 936762f
Signed-off-by: KATOH Yasufumi <karma@jazz.email.ne.jp>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
When a non-thinpool LVM container which have snapshotted clone is
destroyed, the LV of snapshotted clone was also deleted. This patch
prevent it.
The original non-thinpool LVM container of snapshotted clone cannot be
now destroyed.
Signed-off-by: KATOH Yasufumi <karma@jazz.email.ne.jp>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
