diff options
author | Simo Piiroinen <simo.piiroinen@jolla.com> | 2024-04-04 14:02:29 +0300 |
---|---|---|
committer | Kelvin M. Klann <kmk3.code@protonmail.com> | 2024-04-25 09:16:43 -0300 |
commit | e53b6d66b1e9fb81e19af74946e63babf90a7dd6 (patch) | |
tree | 12555af06b5243de62feee7da70b61aee2de60f3 /configure.ac | |
parent | modif: improve flock handling (diff) | |
download | firejail-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