Update the post-install.sh script to set permissions properly…

[savetheclocktower]

…after .deb and .rpm installations.

#1462 identified an issue that is currently affecting all .deb installation on recent Ubuntu, as far as I know. Here's what I see in journalctl after downloading and installing Pulsar 1.131.1 via .deb, then attempting to launch it:

Feb 24 17:14:19 andrew-QEMU-Virtual-Machine systemd[1527]: Started app-gnome-pulsar-6787.scope - Application launched by gnome-shell.
Feb 24 17:14:19 andrew-QEMU-Virtual-Machine kernel: audit: type=1400 audit(1771982059.565:436): apparmor="AUDIT" operation="userns_create" class="namespace" info="Userns create - transitioning profile" profile="unconfined" pid=6787 comm="pulsar" requested="userns_create" target="unprivileged_userns" execpath="/opt/Pulsar/pulsar"
Feb 24 17:14:19 andrew-QEMU-Virtual-Machine kernel: audit: type=1400 audit(1771982059.565:437): apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" pid=6791 comm="pulsar" capability=21  capname="sys_admin"
Feb 24 17:14:19 andrew-QEMU-Virtual-Machine pulsar.desktop[6787]: [6787:0224/171419.567271:FATAL:setuid_sandbox_host.cc(158)] 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 /opt/Pulsar/chrome-sandbox is owned by root and has mode 4755.
Feb 24 17:14:19 andrew-QEMU-Virtual-Machine systemd-coredump[6793]: Process 6787 (pulsar) of user 1000 terminated abnormally with signal 5/TRAP, processing...
Feb 24 17:14:19 andrew-QEMU-Virtual-Machine systemd[1]: Started systemd-coredump@1-6793-0.service - Process Core Dump (PID 6793/UID 0).
Feb 24 17:14:19 andrew-QEMU-Virtual-Machine systemd-coredump[6794]: Resource limits disable core dumping for process 6787 (pulsar).
Feb 24 17:14:19 andrew-QEMU-Virtual-Machine systemd-coredump[6794]: [🡕] Process 6787 (pulsar) of user 1000 terminated abnormally without generating a coredump.
Feb 24 17:14:19 andrew-QEMU-Virtual-Machine systemd[1]: systemd-coredump@1-6793-0.service: Deactivated successfully.
Feb 24 17:14:19 andrew-QEMU-Virtual-Machine systemd[1]: systemd-coredump@1-6793-0.service: Triggering OnSuccess= dependencies.
Feb 24 17:14:19 andrew-QEMU-Virtual-Machine systemd[1]: Starting apport-coredump-hook@1-6793-0.service...
Feb 24 17:14:19 andrew-QEMU-Virtual-Machine systemd[1]: apport-coredump-hook@1-6793-0.service: Deactivated successfully.
Feb 24 17:14:19 andrew-QEMU-Virtual-Machine systemd[1]: Finished apport-coredump-hook@1-6793-0.service.
Feb 24 17:14:28 andrew-QEMU-Virtual-Machine gnome-character[6686]: JS LOG: Characters Application exiting

The app fails to launch, and here's why:

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 /opt/Pulsar/chrome-sandbox is owned by root and has mode 4755.

For guidance on how to handle this, we can consult electron-builder’s own default post-install script:

# Check if user namespaces are supported by the kernel and working with a quick test:
if ! { [[ -L /proc/self/ns/user ]] && unshare --user true; }; then
  # Use SUID chrome-sandbox only on systems without user namespaces:
  chmod 4755 '/opt/${sanitizedProductName}/chrome-sandbox' || true
else
  chmod 0755 '/opt/${sanitizedProductName}/chrome-sandbox' || true
fi

I would've guessed that our post-install script ran in addition to this script, not instead of… but no matter.

We can borrow this snippet and one other relevant snippet we see in the default script: if AppArmor is present, we create an AppArmor profile and install it. This is similar in spirit to the “entitlements” file that we use in macOS: we declare the privileges we need, then AppArmor sandboxes us to use only those privileges.

Without doing more work — and it's dinner time, so that'll have to wait — I cannot tell if the crash described in #1462 is

• only an issue in Pulsar 1.131.1 (and can be avoided by downgrading); or
• suddenly an issue because of an update to Ubuntu (more stringent security) and would affect all versions.

Nonetheless, I was able to get my instance of .deb-installed Pulsar 1.131.1 to stop crashing after I ran

sudo chmod 4755 /opt/Pulsar/chrome-sandbox

so I'm counting this as a win and shipping it. (The AppArmor solution is a bit speculative and designed to give us the benefits of an AppArmor profile without forcing us to upgrade electron-builder; I'll test out the CI artifact and find out if it works.)

Testing

If you've got an Debian or Ubuntu system, feel free to help test by installing the CI-generated .deb and verifying it works correctly. This'll stay in draft until I can do the same, one way or another.

[DeeDeeG]

I support this in principle. 👍 Should be tested some before merging, but I'm announcing that I'm interested in helping get this merged, I am pingable about it, etc.

[savetheclocktower]

@DeeDeeG if you're in a position to verify on Linux x64, would you mind giving it a shot? I keep forgetting that I can't test x64 stuff in a VM. (I'll kick CirrusCI and produce some artifacts if I have to; it just might have to wait a bit.)

[DeeDeeG]

This seems to dovetail well with #1467. (CI there is giving the same error message mentioned in the PR body here.)

Hopefully I can find time to test both, possibly a branch with all of the above changes applied together.

Update: a CI run which has made bins on such a "both PRs" banch: https://github.com/pulsar-edit/pulsar/actions/runs/22466636134 (Linux visual tests failed though. Hmmm.)

Update 2: Ah, the visual tests use the AppImage, which, since using (or in CI's case, extracting) the AppImage doesn't involve "installing," lacks the AppArmor [Chrome sandbox permissions] fix in the postinstall script. So, CI hits an Ubuntu-specific problem without the Ubuntu-specific solution. We can maybe manually fix the AppArmor profile [Chrome sandbox permissions] for the Linux visual tests job in CI, just as the postinstall script would have done... or just install the .deb for the Linux visual tests job.

[DeeDeeG]

FWIW the app built on the combined branch launches fine for me, in a full GUI environment on a real computer (not a VM), caveats yada yada, specifically a Fedora 43 LiveUSB environment.

AppArmor is mainly a Canonical (--> Ubuntu/Debian) thing, not a Fedora thing, from what I can tell. So, Fedora testing doesn't really exercise the AppArmor stuff. But CI seems to fare better on the combined branch with the fixes from this PR.

In fact, launching from the AppImage, without the postinstall script to fix the AppArmor profile, does break on the combined branch's visual tests steps. I should try running package/editor tests on the combined branch to see if those fare any better.

---

Update: See CI runs for the combined branch:

• Editor tests: https://github.com/pulsar-edit/pulsar/actions/runs/22509029132
• Package tests: https://github.com/pulsar-edit/pulsar/actions/runs/22509029121

So, .deb installs with the Chromium sandbox owned by Root and with correct permissions are working; local yarn start or extracting the AppImage contents does not result in the sandbox being owned by Root and both approaches are currently failing in CI (for the combined branch).

It implies the fix fundamentally works but might need some CI fixups to get the issue to be solved in CI too.

[savetheclocktower]

It implies the fix fundamentally works but might need some CI fixups to get the issue to be solved in CI too.

As far as yarn start goes: that task just invokes electron directly, so it wouldn't get the fix from post-install.sh. We could explicitly apply that permissions tweak as a CI step… or we could just add --no-sandbox back to yarn start. The latter would be my vote.

That seems to be the only issue, unless I'm missing something.

[savetheclocktower]

OK, I see it now — here's the step where the post-build sanity check fails. Let me look into this.

The AppImage wasn't treating me right on my Ubuntu VM anyway; something about a weird compression algorithm. I couldn't get it to run without --appimage-extract.

[DeeDeeG]

This appears to be a viable solution, given that it makes the .deb usable on an Ubuntu CI runner even with --no-sandbox removed a-la #1467 on the combined branch.

See this passing run of the package tests workflow on the combined branch: https://github.com/pulsar-edit/pulsar/actions/runs/22509029121

^ The package tests workflow installs Pulsar via the .deb, meaning the full postinstall.sh is running -- the fact CI does not error out appears to validate this present PR, even if #1467 appears to still need a bit further work.

I technically haven't tried the package tests workflow (or the .deb in general) with just the file permissions change or just the AppArmor profile, so maybe a more minimal diff (less elaborate postinstall.sh script) is possible. Furthermore, maybe the AppArmor stuff is unnecessary on e.g. Fedora... So, maybe this PR could be whittled down toward achieving the principle of least change, but... it works, apparently! Good enough for me!

[savetheclocktower]

The “combined” branch @DeeDeeG referred to above also incorporated the changes in #1467; those are a mixed bag. Ideally, we want to minimize the number of situations where we need the --no-sandbox flag. But there's no simple way to get around it for AppImage distributions:

• All the files bundled into an AppImage need to have the same owner, so we can't mess with owner/permissions of chrome-sandbox before we package it
• Applying the proper permissions (the way that it's done in the post-install.sh in this PR) requires use of sudo, so we don't want to make it part of the AppImage’s launch script (thus requiring superuser privileges each time the user launches Pulsar)

But since this PR doesn't attempt to remove --no-sandbox, it appears to be safe to land. We can use #1467 to keep experimenting with --no-sandbox usage and arrive at the right answers.