OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Packages
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by mcaptur - 21.09.2020
Last edited by Petr Štetiar - 27.12.2021

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

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

Closed by  Petr Štetiar
27.12.2021 10:05
Reason for closing:  Works for me
Additional comments about closing:  

I've just tested it on x86/64 with OpenWrt SNAPSHOT r18404-236c3ea730 and it works fine.

Kirill Elagin commented on 20.03.2021 14:47

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.

Kirill Elagin commented on 20.03.2021 14:52

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.

Clemens Fruhwirth commented on 04.04.2021 16:47

The following is a workaround for the problem:

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

gstammw commented on 27.08.2021 16:35

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

Filip Matijević commented on 01.09.2021 07:55

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.

Filip Matijević commented on 06.09.2021 18:33

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?

mcaptur commented on 08.09.2021 05:35

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

Filip Matijević commented on 08.09.2021 17:57

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.

Kirill Elagin commented on 17.11.2021 04:02

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?

Kirill Elagin commented on 17.11.2021 04:34

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

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing