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
```
Signed-off-by: Evgeny Vereshchagin <evvers@ya.ru>
```
==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
```
Signed-off-by: Evgeny Vereshchagin <evvers@ya.ru>
This reverts commit 674791ed75.
Our stable queue tool somehow still listed this patch as pending when it
had already been applied earlier.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
```
$ sudo ./src/tests/lxc-test-lxcpath
=================================================================
==95911==ERROR: LeakSanitizer: detected memory leaks
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).
```
Signed-off-by: Evgeny Vereshchagin <evvers@ya.ru>
```
$ sudo ./src/tests/lxc-test-cgpath
Container creation tests...Passed
Container creation with LXCPATH tests...Passed
=================================================================
==57206==ERROR: LeakSanitizer: detected memory leaks
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)
```
Signed-off-by: Evgeny Vereshchagin <evvers@ya.ru>
This reverts commit 531d36ad00.
Callers might want to explicilty inhert file descriptors so we can't
close them behind their back when we exec.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
if $PATH already contains a path with a space the append of the
default directories in all template scripts fails with an error
like the following:
/usr/share/lxc/templates/lxc-download: 69: export: (x86)/NVIDIA: bad
variable name
Signed-off-by: Christian Ratzenhofer <christian.ratzenhofer@cdnm.at>
instead move networking keys into a subtable. This avoids even just the
remote danger of recursion and also speeds up config parsing.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
It should help the fuzzer to avoid running into timeouts
like https://oss-fuzz.com/testcase-detail/5132999948632064.
Hopefully, once this is merged OSS-Fuzz will report only
infinite loops as timeouts.
Signed-off-by: Evgeny Vereshchagin <evvers@ya.ru>
