aboutsummaryrefslogtreecommitdiffstats
path: root/configure.ac
diff options
context:
space:
mode:
authorLibravatar Simo Piiroinen <simo.piiroinen@jolla.com>2024-04-04 14:02:29 +0300
committerLibravatar Kelvin M. Klann <kmk3.code@protonmail.com>2024-04-25 09:16:43 -0300
commite53b6d66b1e9fb81e19af74946e63babf90a7dd6 (patch)
tree12555af06b5243de62feee7da70b61aee2de60f3 /configure.ac
parentmodif: improve flock handling (diff)
downloadfirejail-e53b6d66b1e9fb81e19af74946e63babf90a7dd6.tar.gz
firejail-e53b6d66b1e9fb81e19af74946e63babf90a7dd6.tar.zst
firejail-e53b6d66b1e9fb81e19af74946e63babf90a7dd6.zip
modif: populate /run/firejail while holding flock
There are reports of firejail sandboxed applications occasionally taking a long time (12 seconds) to start up. When this happens, it affects all sandboxed applications until the device is rebooted. The reason for the slowdown seems to be a timing hazard in the way remounts under /run/firejail are handled. This gets triggered when multiple firejail processes are launched in parallel as part of user session bring up and results in some, dozens, hundreds, or even thousands of stray /run/firejail/xxx mounts. The amount of mount points then affects every mount operation that is done during sandbox filesystem construction. To stop this from happening, arrange it so that only one firejail process at time is inspecting and/or modifying mountpoints under /run/firejail by doing: 1. Create /run/firejail directory (without locking) 2. Create and obtain a lock for /run/firejail/firejail-run.lock 3. Setup files, directories and mounts under /run/firejail 4. Release /run/firejail/firejail-run.lock
Diffstat (limited to 'configure.ac')
0 files changed, 0 insertions, 0 deletions