Skip to content

Conversation

@GytisCepk
Copy link
Contributor

Due to changes in Ubuntu 24.04, sandboxed Electron does not work.

Alternative solution would be to make sure that correct profile is assign to necessary files, but it may complicate our pipelines even more.

It would be great, if someone more familiar with Linux permissions model, would take a look at this.

@aruniverse
Copy link
Member

@markschlosseratbentley iirc youre a linux user, can you take a pass?

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR resolves Electron test failures on Ubuntu 24.04 by implementing a workaround for the platform's new unprivileged user namespace restrictions. The changes add a script to configure chrome-sandbox permissions and update CI pipeline configurations to use ubuntu-latest instead of pinning to ubuntu-22.04.

Changes:

  • Added a new script step in the integration test template to locate and configure chrome-sandbox permissions with setuid bit
  • Updated three Azure pipeline configuration files to use ubuntu-latest instead of ubuntu-22.04
  • Removed comments explaining the previous workaround of pinning to ubuntu-22.04

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File Description
common/config/azure-pipelines/templates/integration-test-steps.yaml Adds script to fix Electron chrome-sandbox permissions on Linux
common/config/azure-pipelines/integration-validation.yaml Updates Linux test matrix entries to use ubuntu-latest
common/config/azure-pipelines/integration-pr-validation.yaml Updates PR validation job to use ubuntu-latest

@markschlosseratbentley
Copy link
Contributor

markschlosseratbentley commented Jan 20, 2026

@markschlosseratbentley iirc youre a linux user, can you take a pass?

Unfortunately, I no longer have a Linux partition. IIRC, @pmconne does.

@pmconne
Copy link
Member

pmconne commented Jan 20, 2026

@aruniverse how do you want it tested - just try to run the core-full-stack integration tests? Or presumably I need to run the actual pipeline?

I presume this is the same or similar issue that I experience whenever trying to run display-test-app?

j2 display-test-app: pmc/anchor-line-patterns 09:31:26 ~/c/j2/s/itwinjs/test-apps/display-test-app 0> npm run start

> display-test-app@1.8.0 start
> cross-env NODE_ENV=development run-p start:webserver start:electron


> display-test-app@1.8.0 start:webserver
> cross-env NODE_ENV=development vite


> display-test-app@1.8.0 start:electron
> electron ./lib/backend/DtaElectronMain.js --inspect --remote-debugging-port=9223

[26868:0120/093133.752231:FATAL:sandbox/linux/suid/client/setuid_sandbox_host.cc:166] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /home/paul/c/j2/s/itwinjs/common/temp/node_modules/.pnpm/electron@39.0.0/node_modules/electron/dist/chrome-sandbox is owned by root and has mode 4755.
/home/paul/c/j2/s/itwinjs/common/temp/node_modules/.pnpm/electron@39.0.0/node_modules/electron/dist/electron exited with signal SIGTRAP
ERROR: "start:electron" exited with 1.

EDIT: yes it's the same error (can we fix the test-apps too or at least document it for other people trying to run them?)

….yaml

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
@GytisCepk
Copy link
Contributor Author

@aruniverse how do you want it tested - just try to run the core-full-stack integration tests? Or presumably I need to run the actual pipeline?

Pipeline is passing. The question is more whether solution is sound.

EDIT: yes it's the same error (can we fix the test-apps too or at least document it for other people trying to run them?)

From what I gather, there is multiple ways to solve this and it's really depends on user's Linux distribution which solution is the best. For that reason, I think, it's up to the user to make sure his environment does not block running sandboxed Electron.

That being said, Ubuntu 24.04 might be common enough case to warrant a note in display-test-app's README.md

SANDBOX_PATH=$(find $PWD/common/temp/node_modules/.pnpm -path "*/electron@*/node_modules/electron/dist/chrome-sandbox" 2>/dev/null | head -n 1)
if [ -f "$SANDBOX_PATH" ]; then
sudo chown root:root "$SANDBOX_PATH"
sudo chmod 4755 "$SANDBOX_PATH"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a comment about what this chmod enables? This is setting execute (5 - read+execute) for all users, correct?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it is decided to leave this, then a comment explaining what it does and why it is acceptable is definitely required. The 4 at the beginning means that chrome-sandbox will execute using the user ID of the file's owner. The file was just changed to be owned by root, so what this is doing is having chrome-sandbox execute as root, with full root privileges. That seems to be the intended fix, but I find it to be very dangerous.

matrix:
Linux_node_20_x:
imageName: ubuntu-22.04 # ubuntu-latest is 24.04, and breaks tests using sandbox
imageName: ubuntu-latest
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we sure we want to swap to latest and not a fixed 24.x? What if latest breaks us again in the future

SANDBOX_PATH=$(find $PWD/common/temp/node_modules/.pnpm -path "*/electron@*/node_modules/electron/dist/chrome-sandbox" 2>/dev/null | head -n 1)
if [ -f "$SANDBOX_PATH" ]; then
sudo chown root:root "$SANDBOX_PATH"
sudo chmod 4755 "$SANDBOX_PATH"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think running chrome-sandbox as root is really bad idea. I would say that if this is the recommended solution, then the people doing the recommending are not very trustworthy.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(But I guess it's possible that I'm missing something, and chrome-sandbox is somehow super safe to run as root. I'm dubious about that, though.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: the fix fix above is for a different program, but I think it can be adapted to work with Electron/chrome-sandbox.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, the following command probably fixes the problem without giving root privileges to the chrome-sandbox process:

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

I believe that this puts the security back to the way it was before 24.04. That's definitely not ideal, but may be better than the current fix. Changing the 0 at the end to 1 restores the original settings.

SANDBOX_PATH=$(find $PWD/common/temp/node_modules/.pnpm -path "*/electron@*/node_modules/electron/dist/chrome-sandbox" 2>/dev/null | head -n 1)
if [ -f "$SANDBOX_PATH" ]; then
sudo chown root:root "$SANDBOX_PATH"
sudo chmod 4755 "$SANDBOX_PATH"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it is decided to leave this, then a comment explaining what it does and why it is acceptable is definitely required. The 4 at the beginning means that chrome-sandbox will execute using the user ID of the file's owner. The file was just changed to be owned by root, so what this is doing is having chrome-sandbox execute as root, with full root privileges. That seems to be the intended fix, but I find it to be very dangerous.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants