FS#3355 - UMDNS: does not start on master with seccomp

[openwrt-bot]

mcaptur:

UMDNS does not start on master with seccomp
this has bee tested on ramips (dir878 and redmiac2100)
if i comment out

procd_set_param seccomp /etc/seccomp/umdns.json

from /etc/init.d/umdns

it works

[openwrt-bot]

kirelagin:

Just a quick bump: this is still an issue in current snapshot.

I tried changing defaultAction to SCMP_ACT_ALLOW in /etc/seccomp/umdns.json, but this doesn’t seem to have any effect and I am still getting Command failed: Request timed out when trying to start the service and daemon.info procd: Instance umdns::instance1 s in a crash loop 7 crashes, 0 seconds since last crash in the logs.

This makes me thin that the issue is not in the seccomp policy itself, but rather in the mechanism that procd uses to apply it.

[openwrt-bot]

kirelagin:

Also, I’m wondering if there is any way to increase the severity/priority for this issue so that someone familiar with the area takes a look at it. I imagine, this issue might be a problem for other people who rely on mdns for accessing systems on their network, as I do.

[openwrt-bot]

clefru:

The following is a workaround for the problem:

cd /etc/seccomp
mv umdns.json umdns1.json
sync
/etc/init.d/umdns restart

[openwrt-bot]

gstammw:

I can confirm that the bug still exists on OpenWrt 21.02.0-rc4.

[openwrt-bot]

filippz:

Just had the same problem with (Archer C7 V5) running 21.02.0-rc4 - the thing is that I have a number of those running the same version that do work. I've tried to compare the configurations and there wasn't anything obvious but I decided to restore config of a working device over the non functional anyway - and it does work after that. Since all of my devices now work I can't debug further.

[openwrt-bot]

filippz:

I've reinstalled couple of my Archers with 21.02.0 and the same issue occurred and it seems that I was wrong before in concluding that restoring configuration helps.
Anyway, **straced **the thing and I saw the call to missing /sbin/seccomp-trace execve("/sbin/seccomp-trace", ...
which is packaged in missing procd-seccomp package:

opkg update && opkg install procd-seccomp && /etc/init.d/umdns start

Can anyone test if installing procd-seccomp fixes the problem for their target devices?

[openwrt-bot]

mcaptur:

@filip yes confirmed adding proc-seccomp fixes umdns on my mt7621 routers. I guess it should be added as a dependency to umdns

[openwrt-bot]

filippz:

That should do it, but I think it's not umdns to blame.

I have a couple of C2600 (IPQ806x custom snapshot built with 5.10 kernel) that have working umdns without procd-seccomp being installed. AFAIK, both C2600 and C7 have kernel that is compiled with seccomp support (they both have /proc/sys/kernel/seccomp folder) and on C2600 it works, and on C7 the procd is trying to call /sbin/seccomp-trace which is not there. I have only umdns installed which is having config in /etc/seccomp but I would assume that any package whit profile there would break on some targets.

So the right this should be to figure out why procd tries to run /sbin/seccomp-trace /sbin/umdns on some targets and simply /sbin/umdns on others

Comparing procd versions on both targets I see that 21.02.0 has an older version 2021-02-23-37eed131-1 while my C2600s are running 2021-08-31-773e8da4-2, so simply updating procd to something more recent might fix this properly.

[openwrt-bot]

kirelagin:

This is the relevant code from procd (it is building the command line to execute).

#ifdef SECCOMP_SUPPORT
if (in->trace)
argv[argc++] = "/sbin/utrace";
else if (seccomp)
argv[argc++] = "/sbin/seccomp-trace";
#else

So, if //procd// is built with seccomp support (which is controlled by make menuconfig) and the init script sets the //seccomp// option (and does not set the //trace// option), ///sbin/seccomp-trace// will be prepended.

I don’t know, it kind of looks like //procd-seccomp// does need to be a dependency of any package whose init scripts request seccomp?

An alternative would be to always install //procd-seccomp// if //CONFIG_SECCOMP// is set and then make packages that want to use it check this configuration option and conditionally keep or remove the seccomp logic in their script?

[openwrt-bot]

kirelagin:

I filed a separate ticket now that the root cause is known.