mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #5897] Shell script fails to kill-off child processes upon app closure and sandbox termination #3125
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#3125
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @TeusLollo on GitHub (Jul 11, 2023).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5897
Description
It seems that, at least on non-
systemddistros (Utilizingrunitas init, in my case) varying zombie processes are leftover upon sandbox termination given interaction withdbus-launch gsettingscommand (Which, on non-systemddistros, is largely necessary to properly set-up custom GTK themes, icons, cursors, and similar) in a custom script.May be at least partially related to https://github.com/netblue30/firejail/issues/3949 and https://github.com/netblue30/firejail/issues/3224
Steps to Reproduce
It is given the following:
A non-
systemddistro (Void Linux, in my case, which runs onrunitas init system)swayas window manager.No login manager (
swayis run on a custom config through a custom script)A
LibreWolfAppImage (From https://gitlab.com/librewolf-community/browser/appimage/-/packages)A custom
.local/share/applications/LibreWolf_Firejailed/freedesktop-based app setup, which operates as follows:LibreWolf_Firejailed.desktopHence,
LibreWolf_Firejailed.desktoploadslibrewolf_firejailed.sh, the latter being thus compiled:Thus,
librewolf_firejailed.shexecutesdbus-launch gsettingsto import relevant custom theming, and relies upon a customlibrewolf_firejailed.profile, the latter being here described:Expected behavior
This fairly involved custom setup was necessary on my side to properly sandbox an AppImage-based browser, and correctly import
$gnome_schemavariables. Indeed, the AppImage-based browser runs perfectly, and correctly imports system themes with this setup (While, without utilizing thedbus-launch gsettings-based schemes, it would absolutely not import custom theming), while otherwise appearing to be properly firejailed. However...Actual behavior
...It appears that, although the AppImage-based browser runs fine, and is properly terminated by the
swayWM (Default keys Super + Shift + Q, depending onswayconfig, thus I remark that the AppImage-based browser is closed-down by the WM), child processes presumably spawned by thedbus-launch gsettingscommands to remain lingering after the sandbox has been closed.In fact:
syslogreports the following:It never however reports on those
dbus-daemonbeing terminated. Also:pstree:Those
dbus-daemonare not visible onpstree. And also:firejail --list:4486:username::firejail --appimage --apparmor --profile=/home/username/.local/share/applications/LibreWolf_Firejailed/librewolf_firejailed.profile /home/username/.bin/LibreWolf.x86_64.AppImageIndeed,
firejail --listdoes not list suchdbus-daemon.ps auxf, however:Those blocks of
remain lingering after EACH sandbox is terminated. Thus, each time the AppImage-browser is closed, a new block of those
is spawned, and remains lingering until system shut-off, or manual termination.
It is even easier to locate such blocks with
htop, but unfortunately pastinghtopoutput is fairly difficult.Behavior without a profile
Not applicable here.
Additional context
Not sure. The above wall of text should be fairly self-evident. This is an edge case, after all, and largely depends upon usage of
dbus-launch gsettings, which is however necessary on nonsystemddistros to ensure that GTK custom theming "sticks".It should also be noted that
swayDM also launches its own scheme ofYet that is not sufficient to force sandboxed applications to import
$gnome_schemavariables.Environment
Void Linux with
runitas init.firejail version 0.9.72
Compile time support:
- always force nonewprivs support is disabled
- AppArmor support is enabled
- AppImage support is enabled
- chroot support is enabled
- D-BUS proxy support is enabled
- file transfer support is enabled
- firetunnel support is disabled
- IDS support is disabled
- networking support is enabled
- output logging is enabled
- overlayfs support is disabled
- private-home support is enabled
- private-cache and tmpfs as user enabled
- SELinux support is disabled
- user namespace support is enabled
- X11 sandboxing support is enabled
Checklist
firejail, since there would never be any use of thedbus-launch gsettingsworkaround).--profile=PROFILENAMEto set the right profile. (Only relevant for AppImages). Indeed I have, and you can read for yourself the contents of such a custom profile above.Log
Logs are provided above, this is an edge case. I can perform more tests if necessary.
@TeusLollo commented on GitHub (Jul 11, 2023):
These are possibly relevant:
https://github.com/netblue30/firejail/issues/3224#issuecomment-586122215
https://github.com/netblue30/firejail/issues/3224#issuecomment-586521087
Maybe I could try something like this https://github.com/netblue30/firejail/issues/3224#issuecomment-590019723, but to me it looks it may be better to find a native solution.
@rusty-snake commented on GitHub (Jul 11, 2023):
Enable
deterministic-shitutdownand try again.@rusty-snake commented on GitHub (Jul 11, 2023):
However, killing zombie processes does not help because killing them is a no-op.
Maybe runit can not collect zombie processes inside pid-namespaces or has some other bug with it?
@TeusLollo commented on GitHub (Jul 11, 2023):
I just modified the script with
firejail --deterministic-shutdown --appimage --apparmor --profile="$HOME/.local/share/applications/LibreWolf_Firejailed/librewolf_firejailed.profile" "$HOME/.bin/LibreWolf.x86_64.AppImage"And no, those zombie processes still linger.
Indeed, it may be a
runitbug, or something else funky going on withdbus-launch.@TeusLollo commented on GitHub (Jul 11, 2023):
Okay, I had a chat with Void Linux devs on IRC:
They say those blocks of
Are not technically zombie processes. Indeed, since those were spawned with
dbus-launch, they are expected to stay around, and would not be picked-up by the init system. Something else must be going on.@TeusLollo commented on GitHub (Jul 11, 2023):
OK, just to clarify, since the documentation isn't entirely helpful on this:
Here
firejailis run from a shell script. Such a shell script launches both a customfirejailcommand, and other dbus-based processes.Is this supported, or should I just close-down the issue?
@TeusLollo commented on GitHub (Jul 11, 2023):
OK, some more chats have confirmed that this probably is not a
firejailissue, but some degree of funkiness with eithergsettingsordbus.Closing this.
@kmk3 commented on GitHub (Jul 11, 2023):
Yes, systemd apparently does some dbus-related things by itself as it depends
on dbus IIRC. dbus is optional when not using systemd, so the dbus commands
have to be executed manually or by something else.
The user dbus process is indeed intended to stay around, but it's usually only
one process and it is usually started with the user session.
What happens if dbus-launch is executed in the sway config and then (after a
reboot) you just call
gsettingsby itself?See for example:
And the following file, which is provided by
dbus-runiton Artix:Maybe Void has something similar.
@TeusLollo commented on GitHub (Jul 11, 2023):
Upon more testing, I have confirmed that, in fact I have no need (Anymore, at least) to use
dbus-launch gsettings, yet, back when I first set-up my config file, it actually was necessary (For some reason, maybe it was because GTK3 was still so unstable? It was back when each version was breaking something...)In every case, it is better to dismiss such an heavy usage of
dbus-launch, given how it can cause system instabilities, and considered also that old sourcing rules still apply to shell scripts, even when involvingdbus, which can cause myriads of troublesome scenarios.Indeed, I have discovered that
swaydoes not even need to be run withdbus-run-session, although it's in some cases preferable.In every case, Void devs have promised to eventually clarify this matter, and their preferred method of setting-up window managers, on their own handbook, thus the matter should eventually be cleared.
Thanks for your help.