[systemd-devel] syscvall-filters killing CGI after update to Fedora 33

[Reindl Harald]

after a long time using this SystemCallFilter perl-cgi with Fedora 33
get killed - anyone an idea what changed that's obviously covered by the
second line

SystemCallFilter=@system-service @network-io @privileged
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount
@obsolete @raw-io @reboot @resources @swap

either the blacklist of the new systemd version convers more than before
or something changed in the perl stack

-----------------

Process 7723 (mailgraph.cgi) of user 48 dumped core.#012#012Stack trace
of thread 7723:#012#0 0x00007f14be8e955d syscall (libc.so.6 +
0xfc55d)#012#1 0x00007f14be2959d2 g_thread_pool_new (libglib-2.0.so.0 +
0x839d2)#012#2 0x00007f14bde5ae5c g_task_get_type_once (libgio-2.0.so.0
+ 0xabe5c)#012#3 0x00007f14bde5af85 g_task_get_type (libgio-2.0.so.0 +
0xabf85)#012#4 0x00007f14bde5b09d g_task_new (libgio-2.0.so.0 +
0xac09d)#012#5 0x00007f14bdfd2c4e pango_fc_font_map_init
(libpangoft2-1.0.so.0 + 0xac4e)#012#6 0x00007f14be37db97
g_type_create_instance (libgobject-2.0.so.0 + 0x39b97)#012#7
0x00007f14be3668c5 g_object_new_internal (libgobject-2.0.so.0 +
0x228c5)#012#8 0x00007f14be36769d g_object_new_with_properties
(libgobject-2.0.so.0 + 0x2369d)#012#9 0x00007f14be368311 g_object_new
(libgobject-2.0.so.0 + 0x24311)#012#10 0x00007f14be5f4d63 rrd_graph_init
(librrd.so.8 + 0x1cd63)#012#11 0x00007f14be5ef33a rrd_graph_v
(librrd.so.8 + 0x1733a)#012#12 0x00007f14be5f3653 rrd_graph (librrd.so.8
+ 0x1b653)#012#13 0x00007f14be639318 n/a (RRDs.so + 0x6318)#012#14
0x00007f14beac02b7 Perl_pp_entersub (libperl.so.5.32 + 0x1082b7)#012#15
0x00007f14beab8040 Perl_runops_standard (libperl.so.5.32 +
0x100040)#012#16 0x00007f14bea36c6c perl_run (libperl.so.5.32 +
0x7ec6c)#012#17 0x0000556a6005934a main (perl + 0x134a)#012#18
0x00007f14be8151e2 __libc_start_main (libc.so.6 + 0x281e2)#012#19
0x0000556a6005938e _start (perl + 0x138e)

Process 2374487 (smokeping_cgi) of user 48 dumped core.#012#012Stack
trace of thread 2374487:#012#0 0x00007f1b1850655d syscall (libc.so.6 +
0xfc55d)#012#1 0x00007f1b17e409d2 g_thread_pool_new (libglib-2.0.so.0 +
0x839d2)#012#2 0x00007f1b17a05e5c g_task_get_type_once (libgio-2.0.so.0
+ 0xabe5c)#012#3 0x00007f1b17a05f85 g_task_get_type (libgio-2.0.so.0 +
0xabf85)#012#4 0x00007f1b17a0609d g_task_new (libgio-2.0.so.0 +
0xac09d)#012#5 0x00007f1b17b7dc4e pango_fc_font_map_init
(libpangoft2-1.0.so.0 + 0xac4e)#012#6 0x00007f1b17f28b97
g_type_create_instance (libgobject-2.0.so.0 + 0x39b97)#012#7
0x00007f1b17f118c5 g_object_new_internal (libgobject-2.0.so.0 +
0x228c5)#012#8 0x00007f1b17f1269d g_object_new_with_properties
(libgobject-2.0.so.0 + 0x2369d)#012#9 0x00007f1b17f13311 g_object_new
(libgobject-2.0.so.0 + 0x24311)#012#10 0x00007f1b1819fd63 rrd_graph_init
(librrd.so.8 + 0x1cd63)#012#11 0x00007f1b1819a33a rrd_graph_v
(librrd.so.8 + 0x1733a)#012#12 0x00007f1b1819e653 rrd_graph (librrd.so.8
+ 0x1b653)#012#13 0x00007f1b181fc318 n/a (RRDs.so + 0x6318)#012#14
0x00007f1b186dd2b7 Perl_pp_entersub (libperl.so.5.32 + 0x1082b7)#012#15
0x00007f1b186d5040 Perl_runops_standard (libperl.so.5.32 +
0x100040)#012#16 0x00007f1b18653c6c perl_run (libperl.so.5.32 +
0x7ec6c)#012#17 0x00005599a814734a main (perl + 0x134a)#012#18
0x00007f1b184321e2 __libc_start_main (libc.so.6 + 0x281e2)#012#19
0x00005599a814738e _start (perl + 0x138e)

[Reindl Harald]

it's the blacklisting of @resources which was as far as i remember a
back-and-forth years ago between dist-upgrades

looks like systemd-246.13-1.fc33.x86_64 is covering too much here in
case of blacklisting

Post by Reindl Harald
after a long time using this SystemCallFilter perl-cgi with Fedora 33
get killed - anyone an idea what changed that's obviously covered by the
second line
@obsolete @raw-io @reboot @resources @swap
either the blacklist of the new systemd version convers more than before
or something changed in the perl stack
-----------------
Process 7723 (mailgraph.cgi) of user 48 dumped core.#012#012Stack trace
of thread 7723:#012#0  0x00007f14be8e955d syscall (libc.so.6 +
0xfc55d)#012#1  0x00007f14be2959d2 g_thread_pool_new (libglib-2.0.so.0 +
0x839d2)#012#2  0x00007f14bde5ae5c g_task_get_type_once (libgio-2.0.so.0
+ 0xabe5c)#012#3  0x00007f14bde5af85 g_task_get_type (libgio-2.0.so.0 +
0xabf85)#012#4  0x00007f14bde5b09d g_task_new (libgio-2.0.so.0 +
0xac09d)#012#5  0x00007f14bdfd2c4e pango_fc_font_map_init
(libpangoft2-1.0.so.0 + 0xac4e)#012#6  0x00007f14be37db97
g_type_create_instance (libgobject-2.0.so.0 + 0x39b97)#012#7
0x00007f14be3668c5 g_object_new_internal (libgobject-2.0.so.0 +
0x228c5)#012#8  0x00007f14be36769d g_object_new_with_properties
(libgobject-2.0.so.0 + 0x2369d)#012#9  0x00007f14be368311 g_object_new
(libgobject-2.0.so.0 + 0x24311)#012#10 0x00007f14be5f4d63 rrd_graph_init
(librrd.so.8 + 0x1cd63)#012#11 0x00007f14be5ef33a rrd_graph_v
(librrd.so.8 + 0x1733a)#012#12 0x00007f14be5f3653 rrd_graph (librrd.so.8
+ 0x1b653)#012#13 0x00007f14be639318 n/a (RRDs.so + 0x6318)#012#14
0x00007f14beac02b7 Perl_pp_entersub (libperl.so.5.32 + 0x1082b7)#012#15
0x00007f14beab8040 Perl_runops_standard (libperl.so.5.32 +
0x100040)#012#16 0x00007f14bea36c6c perl_run (libperl.so.5.32 +
0x7ec6c)#012#17 0x0000556a6005934a main (perl + 0x134a)#012#18
0x00007f14be8151e2 __libc_start_main (libc.so.6 + 0x281e2)#012#19
0x0000556a6005938e _start (perl + 0x138e)
Process 2374487 (smokeping_cgi) of user 48 dumped core.#012#012Stack
trace of thread 2374487:#012#0  0x00007f1b1850655d syscall (libc.so.6 +
0xfc55d)#012#1  0x00007f1b17e409d2 g_thread_pool_new (libglib-2.0.so.0 +
0x839d2)#012#2  0x00007f1b17a05e5c g_task_get_type_once (libgio-2.0.so.0
+ 0xabe5c)#012#3  0x00007f1b17a05f85 g_task_get_type (libgio-2.0.so.0 +
0xabf85)#012#4  0x00007f1b17a0609d g_task_new (libgio-2.0.so.0 +
0xac09d)#012#5  0x00007f1b17b7dc4e pango_fc_font_map_init
(libpangoft2-1.0.so.0 + 0xac4e)#012#6  0x00007f1b17f28b97
g_type_create_instance (libgobject-2.0.so.0 + 0x39b97)#012#7
0x00007f1b17f118c5 g_object_new_internal (libgobject-2.0.so.0 +
0x228c5)#012#8  0x00007f1b17f1269d g_object_new_with_properties
(libgobject-2.0.so.0 + 0x2369d)#012#9  0x00007f1b17f13311 g_object_new
(libgobject-2.0.so.0 + 0x24311)#012#10 0x00007f1b1819fd63 rrd_graph_init
(librrd.so.8 + 0x1cd63)#012#11 0x00007f1b1819a33a rrd_graph_v
(librrd.so.8 + 0x1733a)#012#12 0x00007f1b1819e653 rrd_graph (librrd.so.8
+ 0x1b653)#012#13 0x00007f1b181fc318 n/a (RRDs.so + 0x6318)#012#14
0x00007f1b186dd2b7 Perl_pp_entersub (libperl.so.5.32 + 0x1082b7)#012#15
0x00007f1b186d5040 Perl_runops_standard (libperl.so.5.32 +
0x100040)#012#16 0x00007f1b18653c6c perl_run (libperl.so.5.32 +
0x7ec6c)#012#17 0x00005599a814734a main (perl + 0x134a)#012#18
0x00007f1b184321e2 __libc_start_main (libc.so.6 + 0x281e2)#012#19
0x00005599a814738e _start (perl + 0x138e)

[Dan Nicholson]

Post by Reindl Harald
after a long time using this SystemCallFilter perl-cgi with Fedora 33
get killed - anyone an idea what changed that's obviously covered by the
second line
@obsolete @raw-io @reboot @resources @swap
either the blacklist of the new systemd version convers more than before
or something changed in the perl stack
-----------------
Process 7723 (mailgraph.cgi) of user 48 dumped core.#012#012Stack trace
of thread 7723:#012#0 0x00007f14be8e955d syscall (libc.so.6 +
0xfc55d)#012#1 0x00007f14be2959d2 g_thread_pool_new (libglib-2.0.so.0 +
0x839d2)#012#2 0x00007f14bde5ae5c g_task_get_type_once (libgio-2.0.so.0
+ 0xabe5c)#012#3 0x00007f14bde5af85 g_task_get_type (libgio-2.0.so.0 +
0xabf85)#012#4 0x00007f14bde5b09d g_task_new (libgio-2.0.so.0 +
0xac09d)#012#5 0x00007f14bdfd2c4e pango_fc_font_map_init
(libpangoft2-1.0.so.0 + 0xac4e)#012#6 0x00007f14be37db97

I think the following change in pango is now making it spawn a thread
where it didn't before.

https://gitlab.gnome.org/GNOME/pango/-/commit/e4e7a76a173620394a4bff9738d9b156c40e8c45

--
Dan

[Lennart Poettering]

after a long time using this SystemCallFilter perl-cgi with Fedora 33 get
killed - anyone an idea what changed that's obviously covered by the second
line
@obsolete @raw-io @reboot @resources @swap

@resources is included in @system-service for a reason: it's syscalls
are typically used by programs. Regular system service use it, and
that's totally OK and expected.

i.e. the basically explicitly created a configuration that can't
work. My recommendation: just drop the second line altogether. Your
first line implements an allowlist already, hence besides the
@resources thing the second line is entirely redundant, and the
@resources stuff you really don't want.

either the blacklist of the new systemd version convers more than before or
something changed in the perl stack

Yeah, programs change the APIs they use. System call filters needs to
be put together with an undrstanding what the programs do, and hence
are besten already put togther upstream or by the distro. If you do it
downstream you might run into issues like this.

The idea of @system-service is that it mostly tries to isolate you
from this, but in your case you overrode what it does, so it fell apart.

Lennart

--
Lennart Poettering, Berlin