LXC is being very clever and sometimes maps the caller's uid into the
child userns. This means that the caller can technically write fscaps
that are valid in the ancestor userns (which can be a security issue in
some scenarios) so newer kernels require CAP_SETFCAP to do this. Until
newuidmap/newgidmap are updated to account for this simply write the
mapping directly in this case.
Cc: stable-4.0 Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Fix architecture parsing. So far we couldn't really differ between "want
default architecture" and "failed to parse requested architecture"
because the -1 return value means both. Fix this by using the return
value only to indicate success or failure and return the parsed
personality in a return argument.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
There's no need to making personality handling conditional as it has
been around for such a long time that only weird systems wouldn't have
support for it. And especially if the user requested a specific
personality to be set but the system doesn't support the personality
syscall we should loudly fail instead of moving on.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
We don't build any packages there so it seems we don't need
those packages any more. Apart from that, it should make the
script work on Ubuntu Hirsute where dh-systemd was merged into
debhelper and is no longer available.
Apparently /proc/self/cmd can't be used (reliably) on OSS-Fuzz to figure out
whether the code is run inside the fuzz targets, which causes the
fuzz targets to fill the filesystem with log files.
Related: https://github.com/google/oss-fuzz/issues/5509
Should address https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33835
build-system: turn off lto=thin when building the fuzzers
With lto=thin the fuzzers fail as soon as they start with
```
ERROR: The size of coverage PC tables does not match the
number of instrumented PCs. This might be a compiler bug,
please contact the libFuzzer developers.
Also check https://bugs.llvm.org/show_bug.cgi?id=34636
for possible workarounds (tl;dr: don't use the old GNU ld)
```
ci: link lib[au]san with init.lxc.static statically
init.lxc.static is run in arbitrary containers where the libasan library lxc has been built with
isn't always installed. To make it work let's override GCC's default and link both libasan
and libubsan statically. It should help to fix issues like
```
++ lxc-execute -n c1 -- sudo -u ubuntu /nnptest
lxc-init: error while loading shared libraries: libasan.so.5: cannot open shared object file: No such file or directory
```
apparmor: turn bytes into null-terminated strings before calling strcspn
```
==70349==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000009fb at pc 0x000000433b70 bp 0x7ffcde087810 sp 0x7ffcde086fd0
READ of size 12 at 0x6020000009fb thread T0
#0 0x433b6f in strcspn (/usr/bin/lxc-execute+0x433b6f)
#1 0x7f720413a5cb in apparmor_process_label_get /home/runner/work/lxc/lxc/src/lxc/lsm/apparmor.c:449:8
#2 0x7f720413bc2a in apparmor_prepare /home/runner/work/lxc/lxc/src/lxc/lsm/apparmor.c:1104:13
#3 0x7f720409b6e9 in lxc_init /home/runner/work/lxc/lxc/src/lxc/start.c:848:8
#4 0x7f72040a395a in __lxc_start /home/runner/work/lxc/lxc/src/lxc/start.c:2009:8
#5 0x7f7203fc7186 in lxc_execute /home/runner/work/lxc/lxc/src/lxc/execute.c:99:9
#6 0x7f7204000e44 in do_lxcapi_start /home/runner/work/lxc/lxc/src/lxc/lxccontainer.c:1112:9
#7 0x7f7203ff0c07 in lxcapi_start /home/runner/work/lxc/lxc/src/lxc/lxccontainer.c:1149:8
#8 0x4c6912 in main /home/runner/work/lxc/lxc/src/lxc/tools/lxc_execute.c:224:9
#9 0x7f72034ac0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#10 0x41d93d in _start (/usr/bin/lxc-execute+0x41d93d)
+ echo ---
0x6020000009fb is located 0 bytes to the right of 11-byte region [0x6020000009f0,0x6020000009fb)
allocated by thread T0 here:
#0 0x496399 in realloc (/usr/bin/lxc-execute+0x496399)
#1 0x7f7203fcf85c in fd_to_buf /home/runner/work/lxc/lxc/src/lxc/file_utils.c:463:10
#2 0x7f720413a52b in apparmor_process_label_get /home/runner/work/lxc/lxc/src/lxc/lsm/apparmor.c:442:8
#3 0x7f720413bc2a in apparmor_prepare /home/runner/work/lxc/lxc/src/lxc/lsm/apparmor.c:1104:13
#4 0x7f720409b6e9 in lxc_init /home/runner/work/lxc/lxc/src/lxc/start.c:848:8
#5 0x7f72040a395a in __lxc_start /home/runner/work/lxc/lxc/src/lxc/start.c:2009:8
#6 0x7f7203fc7186 in lxc_execute /home/runner/work/lxc/lxc/src/lxc/execute.c:99:9
#7 0x7f7204000e44 in do_lxcapi_start /home/runner/work/lxc/lxc/src/lxc/lxccontainer.c:1112:9
#8 0x7f7203ff0c07 in lxcapi_start /home/runner/work/lxc/lxc/src/lxc/lxccontainer.c:1149:8
#9 0x4c6912 in main /home/runner/work/lxc/lxc/src/lxc/tools/lxc_execute.c:224:9
```
tests: switch to the "busybox" template in lxc-test-checkpoint-restore
criu can't seem to dump systemd-logind used in Ubuntu due to what appears to be
https://github.com/checkpoint-restore/criu/issues/1430.
Let's switch to busybox where all the processes hopefully can be dumped.
Direct leak of 568 byte(s) in 1 object(s) allocated from:
#0 0x7f8918943bc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
#1 0x7f89181ee5a3 in lxc_container_new /home/vagrant/lxc/src/lxc/lxccontainer.c:5264
#2 0x55ffc5022869 in test_container /home/vagrant/lxc/src/tests/cgpath.c:176
#3 0x55ffc5023023 in main /home/vagrant/lxc/src/tests/cgpath.c:233
#4 0x7f891709e0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
```
Direct leak of 39 byte(s) in 1 object(s) allocated from:
#0 0x7effafc8d3dd in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x963dd)
#1 0x7effaf5a2de6 in lxcapi_config_file_name /home/vagrant/lxc/src/lxc/lxccontainer.c:3190
#2 0x562961680c30 in main /home/vagrant/lxc/src/tests/lxcpath.c:49
#3 0x7effae5150b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
Direct leak of 21 byte(s) in 1 object(s) allocated from:
#0 0x7effafc8d3dd in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x963dd)
#1 0x7effaf5a2de6 in lxcapi_config_file_name /home/vagrant/lxc/src/lxc/lxccontainer.c:3190
#2 0x56296168115e in main /home/vagrant/lxc/src/tests/lxcpath.c:77
#3 0x7effae5150b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
Direct leak of 21 byte(s) in 1 object(s) allocated from:
#0 0x7effafc8d3dd in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x963dd)
#1 0x7effaf5a2de6 in lxcapi_config_file_name /home/vagrant/lxc/src/lxc/lxccontainer.c:3190
#2 0x562961680f0a in main /home/vagrant/lxc/src/tests/lxcpath.c:63
#3 0x7effae5150b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
SUMMARY: AddressSanitizer: 81 byte(s) leaked in 3 allocation(s).
```
Direct leak of 296 byte(s) in 1 object(s) allocated from:
#0 0x7fef22c27dc6 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
#1 0x557c6e3ce3d9 in cgroup_ops_init cgroups/cgfsng.c:3347
#2 0x557c6e3d6516 in cgroup_init cgroups/cgroup.c:33
#3 0x557c6e3788e2 in test_running_container /home/vagrant/lxc/src/tests/cgpath.c:102
#4 0x557c6e379c69 in test_container /home/vagrant/lxc/src/tests/cgpath.c:197
#5 0x557c6e379e37 in main /home/vagrant/lxc/src/tests/cgpath.c:233
#6 0x7fef2136c0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
Direct leak of 296 byte(s) in 1 object(s) allocated from:
#0 0x7fef22c27dc6 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
#1 0x557c6e3ce3d9 in cgroup_ops_init cgroups/cgfsng.c:3347
#2 0x557c6e3d6516 in cgroup_init cgroups/cgroup.c:33
#3 0x557c6e3788e2 in test_running_container /home/vagrant/lxc/src/tests/cgpath.c:102
#4 0x557c6e379c69 in test_container /home/vagrant/lxc/src/tests/cgpath.c:197
#5 0x557c6e379e61 in main /home/vagrant/lxc/src/tests/cgpath.c:237
#6 0x7fef2136c0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
```
projects / thirdparty / lxc.git / log
