Firejail not tearing down sandbox after closing VLC

[Futureknows]

I've noticed a few apps do this when jailed. The app appears to close, but upon inspection the sandbox is still running. With VLC it prevents a new instance from launching until I manually kill the sandbox or the orphaned process.

Has anyone else noticed this behaviour?

[jonleivent]

I have seen this with zombie processes. Firejail keeps jails open if the app that was originally jailed created zombies when it was shut down. These are easy to spot with firetools fstat tool - they show up as jailed processes that use no memory.

[Futureknows]

Thanks. I wonder what might help prevent it, maybe loosening the sandbox? I'll look for common parameters in the offending firejails.

[jonleivent]

I strongly doubt that changing the sandbox parameters will have any effect. If it is a zombie process, then the fault lies with the app itself, not with firejail. There might be a way to enhance firejail itself so that when it notices it has zombie children, it removes them - but that is not a behavior that can be achieved by altering sandbox parameters.

[Futureknows]

The orphaned processes only persist when sandboxed. If I run VLC outside firejail the process closes normally. It seems like it has to be an interaction with the sandbox

…

On Fri, Feb 14, 2020 at 10:21 AM Jonathan Leivent ***@***.***> wrote: I strongly doubt that changing the sandbox parameters will have any effect. If it is a zombie process, then the fault lies with the app itself, not with firejail. There might be a way to enhance firejail itself so that when it notices it has zombie children, it removes them - but that is not a behavior that can be achieved by altering sandbox parameters. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3224?email_source=notifications&email_token=AFAS62YVSHPS3MPKW5SLVVDRC3VMJA5CNFSM4KVBTL72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL2EXUQ#issuecomment-586435538>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAS62YBCCS2G7RKI5I35STRC3VMJANCNFSM4KVBTL7Q> .

[jonleivent]

That is probably because the linux init process already has the ability to deal with zombies that it directly inherits, which is what normally happens when zombies are created . But, if the zombie process is created in a firejail sandbox, then it never gets directly inherited by the linux init process. Not allowing processes to escape a sandbox is normally considered a major firejail feature, but in the case of zombies it is admittedly a nuisance.

I do think it is possible for firejail to handle zombies itself, but it would not be something achievable merely by altering the existing sandboxing parameters. It might require firejail to have some kind of daemon running that watches for the presence of zombie processes in sandboxes. But I'll leave that determination to the firejail developers.

[Futureknows]

I see, thanks for the detailed explanation. I suppose the simplest workaround would be to force firejail to launch VLC in a new sandbox on each instance. Is this possible from firejail's command line?

[glitsj16]

I suppose the simplest workaround would be to force firejail to launch VLC in a new sandbox on each instance. Is this possible from firejail's command line?

Not directly no. You can use a simple shell script wrapper to shutdown any lingering VLC sandbox prior to starting a new one. Here's a basic run-down:

• name the VLC sandbox for easy killing (firejail --shutdown=vlc)
  $ echo "name vlc" >> ${HOME}/.config/firejail/vlc.local

• create the wrapper script

$ cat fj.vlc
#!/bin/sh    
## shutdown potentially lingering VLC sandbox
#+ try native shutdown first
firejail --shutdown=vlc 2> /dev/null || _err=1
#+ try fallback via killall
[ "$_err" ] && killall --quiet --ns 0 vlc
## start a new VLC sandbox
if [ -L /usr/local/bin/vlc ]; then
    #+ using the (firecfg generated) firejail symlink
    /usr/local/bin/vlc &
else
    #+ manually
    firejail /usr/bin/vlc &
fi
exit 0

Place fj.vlc (or whatever you named it) somewhere it gets picked-up first by your PATH, e.g. ${HOME}/bin or /usr/local/bin. If you use a firecfg generated ${HOME}/.local/share/applications/vlc.desktop, make sure to edit the Exec= line, now referencing the fj.vlc command.

[rusty-snake]

Do we want to implement any zombie handling?

[Futureknows]

FYI I have noticed it doesn't happen on all systems, so I don't think it's a high priority.

…

On Wed, May 6, 2020 at 8:41 AM rusty-snake ***@***.***> wrote: Do we want to implement any zombie handling? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3224 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAS622ZUMWYJZFMWDOSZLLRQGALXANCNFSM4KVBTL7Q> .

[rusty-snake]

Has anyone else noticed this behaviour?

When I wrote the wps profiles, I noticed such a behaviour if seccomp was used. There where no violations in the syslog and it had even happen with seccomp.drop @swap.

[rusty-snake]

Do we want to implement any zombie handling?

I think we want. It shouldn't be complicated.