Chromium protects the host by running each page's renderer inside its own sandbox. On Linux that sandbox needs either unprivileged user namespaces or the setuid chrome-sandbox helper. When neither is available, the only way to start Chromium is --no-sandbox, and upstream's image ships exactly that flag, with a comment saying a renderer exploit can then reach the container.

Upstream suggests two ways to turn the sandbox back on: allow unprivileged user namespaces on the host, or run the container with a custom seccomp profile. As far as we can tell, a package can do neither: the manifest has no seccomp setting, and host sysctls are outside the package.

A crawler is software that deliberately opens untrusted pages, so we would rather not ship it unsandboxed without asking first. Three questions:

1. Inside an app container on Cloudron 9.x, are unprivileged user namespaces (unshare --user) allowed, or are they blocked by Docker's default seccomp profile or AppArmor on the host?

2. Is no-new-privileges set on app containers? If not, would a setuid chrome-sandbox helper be an acceptable route, or does the platform discourage setuid binaries in packages?

3. How do existing apps that bundle Chromium handle this? Do they all run --no-sandbox, and is that the accepted practice here?

If the answer is that --no-sandbox is the only option, we plan to say so plainly in the app description, keep the API token mandatory, and rely on the container's own isolation. If there is a better route, we would like to use it.

We can test whatever is suggested on our staging Cloudron and report back here.