fix(linux): Don't setuid chrome-sandbox when not required #8368
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix #7545 (already closed but as stale, not actually fixed)
Setuid for chrome-sandbox is not needed on the vast majority of systems where user namespaces are available, as this more secure mechanism is used for sandboxing instead. Root setuid binaries like this are a general security risk, and appear to cause specific problems in various cases today (e.g. making a deb package unusable on Ubuntu 24.04: httptoolkit/httptoolkit#602, making rpm packages fail validation on Fedora: bitwarden/clients#5153)
User namespaces were implemented in 2013 (kernel 3.8), and have been enabled by default widely for many years. Chrome themselves stopped setting this in 2016, describing it as unnecessary on all supported Linux platforms: https://issues.chromium.org/issues/40462640.
The only other case I'm aware of where setuid is required despite user namespace support is Electron <5. This electron version has been end-of-life since 2019 (more than 4 years ago) so hopefully that's not a concern, but if Electron Builder supports very old electron versions then this may be a breaking change.
This PR checks whether they're supported (i.e.
/proc/self/ns/user
is a symlink) and briefly tests that they work correctly (runningtrue
in a separate user namespace), and then sets the setuid bit only if that fails. This is the same test approach as used to detect sandboxing support in Nix: https://github.com/NixOS/nix/blob/40f80e1b5cf2bebb6d1d8c9efac1d982a540d555/tests/functional/common/vars-and-functions.sh#L180-L182