Process-control auto-connection request for chameleon snap

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-backend" sig=0 arch=c000003e syscall=203 compat=0 ip=0x7fd4de28cef7 code=0x50000

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 :frowning: 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:

plugs:
  browser-sandbox:
    interface: browser-support
    allow-sandbox: true
apps:
  chameleon:
    plugs:
    ...
    - browser-sandbox

then I suspect your snap will start working.

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 :frowning:
peoplecd
info@peoplecd.com

Ok. Are you then saying that disabling the internal chromium sandbox (use --no-sandbox) and just relying on the snapd sandbox is undesirable?

@roadmr - can you take a look at this?

Yes, --no-sandbox is totally fine.

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)…

Unfortunately i don’t have control on dotnet core internals behavior. :frowning:

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.

UPDATE: I’ve created issue on dotnet’s repo.

1 Like

@jdstrand ping.
Can I do something else?

@jdstrand Any progress on this?
@roadmr Can you transfer snap?

Sorry! I missed the transfer request because it was mixed up with the other requests in this thread :slight_smile:

I’ll email you to confirm.

  • Daniel
1 Like

@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 with allow-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?

@jdstrand I’m main developer of chameleon, had full access to source code and snapcraft account.

+1 for use of browser-support with ‘allow-sandbox: true’.

@reviewers - can others vote?

+1 from me too for use of browser-support with allow-sandbox: true

2 votes for, 0 against. Granting use of browser-support with ‘allow-sandbox: true’ to this official browser snap. This is now live.