It turns out that the problem is related to how dotnet tries to modify a child process. It uses a system call that could modify any process, since it takes an arbitrary PID as the first argument. This is a snap no-no, although supposedly there’s a workaround using a manually-connected process-control plug (but it’s not working for me). But this manual CLI step would still be a pain for normal users.
Further info at these links:
Hi,
I want to enable auto-connecting process-control interface to chameleon snap .
Here are some technical details. Chameleon is electron app, which spawns aspnet core 3.0 self-contained back-end for serving its UI content.
With devmode app runs perfectly, but with strict backend child process fails to start.
I was able to track down problem to this syslog message
SECCOMP auid=1000 uid=1000 gid=1000 ses=1 pid=4917 comm="chameleon-backe" exe="/snap/chameleon/7/resources/backend/chameleon-backen…
dotnet:master ← lucyllewy:issue-1634
Unfortunately there are limitations in the sandbox mediation for this API. Speci… fically, while we can mediate `sched_setaffinity` via the syscall filter, we are not able to say 'allow this for child pids'/etc; this is a limitation of the kernel. We do allow `sched_setaffinity(0, ...)` in the default policy. We could allow a bare `sched_setaffinity` rule (which is what process control does), but that would allow specifying arbitrary pids as the first argument. AppArmor allows us to mediate CAP_SYS_NICE (which we allow in process-control) which is needed to set the affinity for processes with a differing euid/ruid than the current euid, but even without CAP_SYS_NICE, allowing arbitrary use of `sched_setaffinity` would allow setting the affinity for any process within the user's session and would allow snap daemons (which may run as root) to set the affinity for any root process on the system. The `process-control` interface is the current means to grant access to this API to snaps. Unfortunately, since it allows influencing other snaps and the system (for this API and more), it is manually connected.
In terms of future enhancements, the seccomp implementation in the kernel is called at a point where it doesn't have the context to know if the target pid is a child or not. Perhaps AppArmor could grow fine-grained mediation for this to allow setting the affinity for childen, but this is likely challenging to do in a performant manner (and would not be something that would be useful for a long time even if it were implemented today). AFAIK, there is no cgroup facility that could be employed that would limit the use of `sched_setaffinity` to as certain set of pids (we can only limit the CPUs).
While we can evaluate each request to grant snaps access to `process-control`, a more developer-friendly mechanism for consumers of dotnet runtime is preferred. Perhaps dotnet runtime can shuffle this code around a bit to have the child call `sched_setaffinity(0, ...)`?
