When cgroup creation failed we reset container_cgroup to NULL to avoid
issues with __cleanup__. Fix that logic:
- add steal_ptr() based on take_ptr()
- move stealing the pointer out of the loop
lxc ctImport 20190210050705.858 DEBUG network - network.c:instantiate_veth:202 - Instantiated veth "vethGQMH7I/vethSPXNL3", index is "272"
lxc ctImport 20190210050705.858 ERROR cgfsng - cgroups/cgfsng.c:mkdir_eexist_on_last:1262 - File exists - Failed to create directory "/sys/fs/cgroup/unified//lxc.payload/ctImport-0"
lxc ctImport 20190210050705.858 ERROR cgfsng - cgroups/cgfsng.c:container_create_path_for_hierarchy:1302 - Failed to create cgroup "/sys/fs/cgroup/unified//lxc.payload/ctImport-0"
lxc ctImport 20190210050705.858 ERROR cgfsng - cgroups/cgfsng.c:cgfsng_payload_create:1431 - Failed to create cgroup "/sys/fs/cgroup/unified//lxc.payload/ctImport-0"
lxc ctImport 20190210050705.858 INFO cgfsng - cgroups/cgfsng.c:cgfsng_payload_create:1441 - The container uses "lxc.payload/ctImport-0" as cgroup
lxc ctImport 20190210050705.858 ERROR cgfsng - cgroups/cgfsng.c:mkdir_eexist_on_last:1262 - File exists - Failed to create directory "/sys/fs/cgroup/unified/"
lxc ctImport 20190210050705.858 ERROR cgfsng - cgroups/cgfsng.c:container_create_path_for_hierarchy:1302 - Failed to create cgroup "/sys/fs/cgroup/unified/"
lxc ctImport 20190210050705.858 ERROR cgfsng - cgroups/cgfsng.c:cgfsng_payload_create:1431 - Failed to create cgroup "/sys/fs/cgroup/unified/"
lxc ctImport 20190210050705.858 INFO cgfsng - cgroups/cgfsng.c:cgfsng_payload_create:1441 - The container uses "(null)" as cgroup
Fixes: d97919abf22 ("cgroups: partially switch to cleanup macros") Reported-by: Stéphane Graber <stgraber@ubuntu.com> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Warn whenever a local variable or type declaration shadows another
variable, parameter, type, class member (in C++), or instance variable
(in Objective-C) or whenever a built-in function is shadowed.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Warn whenever a function is defined with a return type that defaults to
int. Also warn about any return statement with no return value in a
function whose return type is not void (falling off the end of the
function body is considered returning without a value).
For C only, warn about a return statement with an expression in a
function whose return type is void, unless the expression type is also
void. As a GNU extension, the latter case is accepted without a warning
unless -Wpedantic is used.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Rachid Koucha [Tue, 29 Jan 2019 11:20:46 +0000 (12:20 +0100)]
More accurate error msg for template file
When calling lxc-create, if the template exists but is not executable, we end with the following error messages which make believe that the template file does not exist when it is merely a execute access problem:
lxc-create: ctn00: utils.c: get_template_path: 918 No such file or directory - bad template: /.../lxc-busybox
lxc-create: ctn00: lxccontainer.c: do_lxcapi_create: 1786 Unknown template "/.../lxc-busybox"
lxc-create: ctn00: tools/lxc_create.c: main: 327 Failed to create container ctn00
Actually internally the errno is lost as the following code triggers a useless access to (strace output):
access("/.../lxc-busybox", X_OK) = -1 ENOENT (No such file or directory)
With the above fix, we get a more explicit error message when the template file is missing the "execute" bit:
lxc-create: bbc: utils.c: get_template_path: 917 Permission denied - Bad template pathname: /tmp/azerty
lxc-create: bbc: lxccontainer.c: do_lxcapi_create: 1816 Unknown template "/tmp/azerty"
lxc-create: bbc: tools/lxc_create.c: main: 331 Failed to create container bbc
With the above fix, we get a more explicit error message when the pathname of the template file is incorrect:
lxc-create: bbc: utils.c: get_template_path: 917 No such file or directory - Bad template pathname: /tmp/qwerty
lxc-create: bbc: lxccontainer.c: do_lxcapi_create: 1816 Unknown template "/tmp/qwerty"
lxc-create: bbc: tools/lxc_create.c: main: 331 Failed to create container bbc
Rachid Koucha [Sun, 27 Jan 2019 12:46:48 +0000 (13:46 +0100)]
/etc/resolv.conf grows indefinitely
This file grows indefinitely : upon each DHCP lease renew,
the "nameserver ..dns..." line is added at the end of the file.
Make a "grep" in the file to make sure that the same line
does not already exist.
Rachid Koucha [Sun, 27 Jan 2019 02:38:36 +0000 (03:38 +0100)]
Installation of default.script for udhcpc
The busybox template installs default.script in /usr/share/udhcpc/.
But the pathname of "default.script" may vary from one busybox
build to another. As the pathname is displayed in udhcpc's help,
grab it from it.
Rachid Koucha [Sat, 26 Jan 2019 23:10:39 +0000 (00:10 +0100)]
Avoid risk of "too far memory read"
As we call "lxc_add_state_client(fd, handler, (lxc_state_t *)req->data)"
which supposes that the last parameter is a table of MAX_STATE
entries when calling memcpy():
memcpy(newclient->states, states, sizeof(newclient->states))
Rachid Koucha [Sat, 26 Jan 2019 22:46:34 +0000 (23:46 +0100)]
Avoid double lxc-freeze/unfreeze
If we call lxc-freeze multiple times for an already frozen container, LXC
triggers useless freezing by writing into the "freezer.state" cgroup file.
This is the same when we call lxc-unfreeze multiple times.
Checking the current state with a LXC_CMD_GET_STATE
(calling c->state) would permit to check if the container is FROZEN
or not.
The reverted branch breaks starting all seccomp confined containers. Not
even a containers with our standard seccomp profile starts correctly.
This is strong evidence that these changes have never been tested even
with a standard workload. That is unacceptable!
We are still happy to merge that feature but going forward we want tests
that verify that standard workloads and new features work correctly.
seccomp is a crucial part of our security story and I will not let the
be compromised by missing tests!
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
LiFeng [Wed, 16 Jan 2019 10:07:59 +0000 (05:07 -0500)]
seccomp: add rules for specified architecture only
If the architecture is specified in the seccomp configuration, like:
```
2
whitelist errno 1
[x86_64]
accept allow
accept4 allow
```
We shoud add rules only for amd64 instead of add rules for
x32/i386/amd64.
1. If the [arch] was not specified in seccomp config, add seccomp rules
for all all compat architectures.
2. If the [arch] specified in seccomp config irrelevant to native host
arch, the rules will be ignored.
3. If specified [all] in seccomp config, add seccomp rules for all
compat architectures.
4. If specified [arch] as same as native host arch, add seccomp rules
for the native host arch.
5. If specified [arch] was not native host arch, but compat to host
arch, add seccomp rules for the specified arch only, NOT add seccomp
rules for native arch.
projects / thirdparty / lxc.git / log
