Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
openwrt-bot opened this issue Sep 21, 2020 · 10 comments
Closed

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

openwrt-bot opened this issue Sep 21, 2020 · 10 comments
Labels

Comments

@openwrt-bot
Copy link

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

gstammw:

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

@openwrt-bot
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

kirelagin:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant