idea: UI freeze due to chromium + seccomp

[felixwiemuth]

Description

The profile for IntelliJ Idea includes seccomp, but this (at least recently) seems to cause problems with opening new projects (and potentially also running programs from the IDE).

This happened for IntelliJ Idea Ultimate 2024.2.3 (after updating to this version, could not run run configurations anymore (which worked just before) until disabling seccomp). A crash when opening projects (which one hadn't opened before) happened for this and versions 2024.2.1 and 2024.2.2. What is printed on the console as the last thing around the time when the program gets stuck and then closes is:

FATAL:zygote_host_impl_linux.cc(216)] Check failed: . : No such file or directory (2)

It seems that zygote is related to Chromium: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/linux/zygote.md
I noticed that after disabling seccomp, the Readme of the project is displayed after loading it - a guess would be that this is displayed via Chromium, which causes the crash when it wants to fork the process or so.

The profile used is based on the profile coming with firejail, but whitelisted, and with a few other restrictions removed.

Steps to Reproduce

1. Run IntelliJ Idea with the idea.sh firejail profile: firejail --profile=... intellij-idea-ultimate-edition
2. Open a new project (e.g. gradle project) that hadn't been opened before with IntelliJ Idea (it might be required that the project has a README.md if the issue is related to this)
3. Wait while the project is imported/scanned etc.
4. See the UI getting stuck after half a minute or so, see error FATAL:zygote_host_impl_linux.cc(216)] Check failed: . : No such file or directory (2) on the console

Expected behavior

The IDE does not crash

Actual behavior

The IDE crashes

Behavior without a profile

The IDE does not crash (when just removing seccomp from the profile)

Environment

• Name/version/arch of the Linux kernel (uname -srm): Linux 6.6.47-1-MANJARO x86_64
• Name/version of the Linux distribution: Manjaro/Arch Linux
• Version of Firejail (firejail --version): 0.9.72

Checklist

• The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it). (by the profile)
• [most likely] I can reproduce the issue without custom modifications (e.g. globals.local).
• The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
• The profile (and redirect profile if exists) hasn't already been fixed upstream.
• I have performed a short search for similar issues (to avoid opening a duplicate).
  • I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.
• I used --profile=PROFILENAME to set the right profile. (Only relevant for AppImages)

[rusty-snake]

So which syscall is blocked?

firejail/etc/templates/syscalls.txt

Lines 89 to 112 in 0e7296b

	What to do if seccomp breaks a program
	--------------------------------------
	Start `journalctl --grep=SECCOMP --follow` in a terminal and run
	`firejail --seccomp-error-action=log /path/to/program` in a second terminal.
	Now switch back to the first terminal (where `journalctl` is running) and look
	for the numbers of the blocked syscall(s) (`syscall=<NUMBER>`). As soon as you
	have found them, you can stop `journalctl` (^C) and execute
	`firejail --debug-syscalls | grep NUMBER` to get the name of the syscall.
	In the particular case that it is a 32bit syscall on a 64bit system, use `firejail --debug-syscalls32 | grep NUMBER`.
	Now you can add a seccomp exception using `seccomp !NAME`.
	If the blocked syscall is ptrace, consider to add allow-debuggers to the profile.
	```
	term1$ journalctl --grep=SECCOMP --follow
	term2$ firejail --seccomp-error-action=log /usr/bin/signal-desktop
	term1$ (journalctl --grep=SECCOMP --follow)
	audit[1234]: SECCOMP ... comm="signal-desktop" exe="/usr/bin/signal-desktop" sig=31 arch=c000003e syscall=161 ...
	^C
	term1$ firejail --debug-syscalls | grep "^161[[:space:]]"
	161 - chroot
	```
	Profile: `seccomp -> seccomp !chroot`

If it is related to chromium, try seccomp !chroot assuming user namespaces are enabled.