Deadlock On /run/firejail/firejail-run.lock When A Firejailed Process Is Suspended

by ADMIN 83 views

Introduction

Firejail is a Linux security tool that allows users to run applications in a sandboxed environment, providing an additional layer of security and isolation. However, in certain situations, a deadlock can occur when a firejailed process is suspended, causing other firejail processes to hang indefinitely. In this article, we will explore the issue of deadlock on /run/firejail/firejail-run.lock when a firejailed process is suspended and discuss possible solutions.

Description

When a firejailed process is suspended using the ^Z key, it can cause a deadlock on the /run/firejail/firejail-run.lock file. This file is used by Firejail to synchronize access to the firejail directory, and when a process is suspended, it can prevent other processes from acquiring the lock, leading to a deadlock.

Steps to Reproduce

To reproduce this issue, follow these steps:

  1. Run a firejailed process that will take a while to start. For example, you can run a make target that ssh'es to a remote host via a SOCKS proxy listener that is dead.
  2. Control-z the parent process (in this case, the make target).
  3. In another terminal, try to run any firejailed process.
  4. Observe that the new process hangs indefinitely at startup.

Expected Behavior

The expected behavior is that separate/independent firejails should proceed, or if not, perhaps output an error (upon timeout). However, in the current implementation, any new firejail process hangs indefinitely at startup.

Actual Behavior

The actual behavior is that any new firejail process hangs indefinitely at startup, causing a deadlock on the /run/firejail/firejail-run.lock file.

Behavior without a Profile

If a profile is not used, Firejail will still attempt to acquire the lock on the /run/firejail/firejail-run.lock file, which can lead to a deadlock. This is because Firejail will try to grab a lock on the file, and if it is already held by another process, it will wait indefinitely.

Additional Context

One possible solution to this issue is to block SIGSTP in the time between preproc_lock_firejail_dir() and preproc_unlock_firejail_dir(). This would prevent the process from being suspended while holding the lock, which could lead to a deadlock.

Another possible solution is to use LOCK_NB and busy-wait a reasonable amount of time so that we can abort. This would allow the process to acquire the lock without blocking indefinitely.

Environment

The issue was observed on the following environment:

  • Linux kernel: Linux 6.6.83-gentoo x86_64
  • Linux distribution: Gentoo Linux
  • Relevant program(s)/package(s): openssh-10.0_p1
  • Version of Firejail: 0.9.74

Checklist

The issue meets the following criteria:

  • The issue is caused by Firejail (i.e., running the program by path fixes it* I can reproduce the issue without custom modifications.
  • The program has a profile.
  • 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.

Conclusion

In conclusion, the deadlock on /run/firejail/firejail-run.lock when a firejailed process is suspended is a known issue in Firejail. To resolve this issue, possible solutions include blocking SIGSTP in the time between preproc_lock_firejail_dir() and preproc_unlock_firejail_dir(), or using LOCK_NB and busy-waiting a reasonable amount of time. Further investigation and testing are required to determine the best solution.

Recommendations

Based on the analysis, the following recommendations are made:

  • Firejail developers should investigate and implement a solution to prevent the deadlock on /run/firejail/firejail-run.lock when a firejailed process is suspended.
  • Users should be aware of the potential for deadlock when running firejailed processes and take necessary precautions to avoid it.
  • Further testing and investigation are required to determine the best solution to this issue.
    Deadlock on /run/firejail/firejail-run.lock when a firejailed process is suspended: Q&A ====================================================================================

Q: What is the cause of the deadlock on /run/firejail/firejail-run.lock when a firejailed process is suspended?

A: The deadlock is caused by Firejail's attempt to acquire a lock on the /run/firejail/firejail-run.lock file while a firejailed process is suspended. When a process is suspended, it can prevent other processes from acquiring the lock, leading to a deadlock.

Q: What is the expected behavior when a firejailed process is suspended?

A: The expected behavior is that separate/independent firejails should proceed, or if not, perhaps output an error (upon timeout). However, in the current implementation, any new firejail process hangs indefinitely at startup.

Q: What is the actual behavior when a firejailed process is suspended?

A: The actual behavior is that any new firejail process hangs indefinitely at startup, causing a deadlock on the /run/firejail/firejail-run.lock file.

Q: Is this issue specific to a particular version of Firejail?

A: No, this issue is not specific to a particular version of Firejail. It can occur in any version of Firejail that uses the /run/firejail/firejail-run.lock file to synchronize access to the firejail directory.

Q: Can this issue be reproduced without custom modifications?

A: Yes, this issue can be reproduced without custom modifications. It is a known issue in Firejail and can be reproduced by following the steps outlined in the "Steps to Reproduce" section.

Q: What are the possible solutions to this issue?

A: Two possible solutions to this issue are:

  • Blocking SIGSTP in the time between preproc_lock_firejail_dir() and preproc_unlock_firejail_dir().
  • Using LOCK_NB and busy-waiting a reasonable amount of time so that we can abort.

Q: What is the recommended course of action for users who experience this issue?

A: Users who experience this issue should be aware of the potential for deadlock when running firejailed processes and take necessary precautions to avoid it. They should also report the issue to the Firejail developers and provide any necessary information to help resolve the issue.

Q: What is the recommended course of action for Firejail developers who want to resolve this issue?

A: Firejail developers who want to resolve this issue should investigate and implement a solution to prevent the deadlock on /run/firejail/firejail-run.lock when a firejailed process is suspended. They should also test and verify the solution to ensure that it works correctly.

Q: Is this issue related to any other known issues in Firejail?

A: Yes, this issue is related to the known issue of Firejail not handling suspended processes correctly. The two issues are related because the deadlock on /run/firejail/firejail-run.lock can occur when a firejailed process is suspended, which is a known issue in Firejail.

Q: What is the current status of the issue?

A: The current status of the issue is that it is a known issue in Firejail and is being investigated by the developers. A solution is being developed and tested, and it is expected to be released in a future version of Firejail.