As I understand dotnetcore calls sched_setaffinity kernel function, which is not allowed by seccomp rules and I donât have any control on it Adding process-control interface fixes issue. But without auto-connecting it app is totally unusable.
The browser-support interface includes sched_setscheduler when using âallow-sandbox: trueâ. This is often used when the application has the chromium content apiâs sandbox enabled. If you adjust your snap to use:
However, this will trigger a manual review in the store because use of the âallow-sandboxâ attribute of the browser-support interface is reserved for vetted publishers since it grants additional privileged accesses.
For regular electron apps, we advise disabling the internal chromium sandbox (use --no-sandbox) and just relying on the snapd sandbox and browser-support as you are using it now. For full blown browsers (eg, opera, brave, etc), we can perform publisher vetting and grant you use of browser-support with allow-sandbox: true, as described above.
Can you describe chameleon in more detail and how it might relate to other major browsers or to typical electron apps?
Chameleon is engine, that allows you to create browser with limited/managed content. For example parent can âcreate browserâ for his kid. You can see usage example in this video.
In video you can see two icons - Chameleon and Zac Browser. Chameleon is admin part (accessed by parent), and Zac Browser is part for kid. From technical point of view they both launch same electron app executable, but with different command line arguments.
Since content could be any URL from internet, chameleon is more full blown browser, than regular electron app.
BTW, could you also transfer snap ownership to publisherâs account? Iâve made mistake and created snap under my personal account peoplecdinfo@peoplecd.com
Ok, you should then be able to update your electron build to use --no-sandbox and simply plugs browser-support without allow-sandbox: true, which should stop the use of sched_setscheduler() and remove the need for process-contol. Your snap will also pass automated review.
I think i misunderstood something - electron app already uses --no-sandbox, but the backend sub-process, which is aspnet core app, still needs sched_setscheduler
Is this configurable? CAP_SYS_NICE is needed to use it and the browser should be running as non-root (unless you have a setuid binary (which isnât allowed by the store and shouldnât be present with --no-sandbox) or snap daemon running)âŚ
Iâve created simple dotnet core console app and bundled it into snap. The result is same - snap required process control. I created strace log for it.
As I understand from log, sched_setaffinity and sched_getaffinity are used to manipulate appâs process child processes created with clone() function - in other words threads. So CAP_SYS_NICE should not be required.
@soarc - the problem with sched_setaffinity is its first argument which takes an arbitrary pid so the sandbox doesnât allow it without process control.
Considering our prior discussion, I think a better approach would be to use browser-support withallow-sandbox: true provided this snap represents an official snap of chameleon. This should help futureproof the use of the snap.
Before we do that, are you affiliated with upstream chameleon? If so, in what capacity?
Adding process-control interface fixes issue. But without auto-connecting it app is totally unusable.