[GH-ISSUE #3130] firejail randomly elevates itself from standard user to root

gitea-mirror commented

2026-05-05 08:37:39 -06:00

Owner

Originally created by @mavrent on GitHub (Jan 7, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3130

I'll have firejail running, leave a website open for a few hours, and when I come back and look at top, one of firejail's 2 processes will be running as root.

How do I look into why this is happening? I'm using nsjail until I understand this better.

It's been happening intermittently the whole time I've been using firejail and has already happened once since 0.9.62.

Originally created by @mavrent on GitHub (Jan 7, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3130 I'll have firejail running, leave a website open for a few hours, and when I come back and look at top, one of firejail's 2 processes will be running as root. How do I look into why this is happening? I'm using nsjail until I understand this better. It's been happening intermittently the whole time I've been using firejail and has already happened once since 0.9.62.

gitea-mirror

2026-05-05 08:37:39 -06:00

closed this issue
added the
invalid
label

gitea-mirror commented

2026-05-05 08:37:42 -06:00

Author

Owner

@ghost commented on GitHub (Jan 7, 2020):

Please provide as much details about the environment you're seeing this in: OS, the web browser in question, how you start the sandbox, whether the top command you mention is the firejail --top option, etcetera.

For debugging purposes firejail has a few specific options, explained in detail in the man page. Besides --debug there's also --allow-debuggers (which allows using strace). I would recommend starting the sandbox in question from the command line to gather as much data as possible.

@ghost commented on GitHub (Jan 7, 2020): Please provide as much `details` about the environment you're seeing this in: OS, the web browser in question, how you start the sandbox, whether the top command you mention is the firejail --top option, etcetera. For debugging purposes firejail has a few specific options, explained in detail in the man page. Besides `--debug` there's also `--allow-debuggers` (which allows using strace). I would recommend starting the sandbox in question from the command line to gather as much data as possible.

gitea-mirror commented

2026-05-05 08:37:42 -06:00

Author

Owner

@mavrent commented on GitHub (Jan 7, 2020):

Please provide as much details about the environment you're seeing this in: OS, the web browser in question, how you start the sandbox, whether the top command you mention is the firejail --top option, etcetera.

OS: Arch Linux, latest linux-hardened kernel: (upstream: https://github.com/anthraxx/linux-hardened)
Top program: htop
Shell, UI: starting from a bash shell, running inside Xorg, Xfce desktop environment
Has happened running both browsers using these commands to start firejail: firejail firefox, firejail chromium

I'll start running firejail with --debug to see if I can get information when I encounter the bug again.

@mavrent commented on GitHub (Jan 7, 2020): > Please provide as much `details` about the environment you're seeing this in: OS, the web browser in question, how you start the sandbox, whether the top command you mention is the firejail --top option, etcetera. > OS: Arch Linux, latest linux-hardened kernel: (upstream: https://github.com/anthraxx/linux-hardened) Top program: htop Shell, UI: starting from a bash shell, running inside Xorg, Xfce desktop environment Has happened running both browsers using these commands to start firejail: firejail firefox, firejail chromium I'll start running firejail with --debug to see if I can get information when I encounter the bug again.

gitea-mirror commented

2026-05-05 08:37:43 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 7, 2020):

firejail is a suid binary, a firejail process running as root is not unexpected in general. What shows ps -eFjH | grep -E "^root.*firejail" --context=4?

@rusty-snake commented on GitHub (Jan 7, 2020): firejail is a suid binary, a firejail process running as root is not unexpected in general. What shows `ps -eFjH | grep -E "^root.*firejail" --context=4`?

gitea-mirror commented

2026-05-05 08:37:44 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 7, 2020):

S1: shell1, S2: shell2, S3: shell3

S1$ firejail --name=test --noprofile sleep 1m
S2$ ps -eFjH | grep -E "^root.*firejail" --context=4
# Empty
S3$ firejail --join=test sleep 5s
S2$ ps -eFjH | grep -E "^root.*firejail" --context=4

A few notes:

firejail --join=test whoami shows my user
process hierarchy (only the second process runs as root (as expected because of suid)):

- /usr/bin/zsh
   - firejail --join=test sleep 5s
      - sleep 5s

This suid process is terminated/replaced if running "normal", but stays if using --join @netblue30 is this expected?

@rusty-snake commented on GitHub (Jan 7, 2020): S1: shell1, S2: shell2, S3: shell3 ``` S1$ firejail --name=test --noprofile sleep 1m S2$ ps -eFjH | grep -E "^root.*firejail" --context=4 # Empty S3$ firejail --join=test sleep 5s S2$ ps -eFjH | grep -E "^root.*firejail" --context=4 ``` A few notes: 1. `firejail --join=test whoami` shows my user 2. process hierarchy (only the second process runs as root (as expected because of suid)): ``` - /usr/bin/zsh - firejail --join=test sleep 5s - sleep 5s ``` 3. This suid process is terminated/replaced if running "normal", but stays if using --join @netblue30 is this expected?

gitea-mirror commented

2026-05-05 08:37:45 -06:00

Author

Owner

@smitsohu commented on GitHub (Jan 8, 2020):

@mavrent Could you please run grep Uid /proc/PID/status when you encounter this again? Do you use --join or --join-or-start in this context?

@smitsohu commented on GitHub (Jan 8, 2020): @mavrent Could you please run `grep Uid /proc/PID/status` when you encounter this again? Do you use `--join` or `--join-or-start` in this context?

gitea-mirror commented

2026-05-05 08:37:45 -06:00

Author

Owner

@mavrent commented on GitHub (Jan 8, 2020):

@mavrent Could you please run grep Uid /proc/PID/status when you encounter this again? Do you use --join or --join-or-start in this context?

Okay. No, I just run a browser in firejail vanilla, sometimes with --nodbus or --x11=xorg.

@mavrent commented on GitHub (Jan 8, 2020): > @mavrent Could you please run `grep Uid /proc/PID/status` when you encounter this again? Do you use `--join` or `--join-or-start` in this context? Okay. No, I just run a browser in firejail vanilla, sometimes with --nodbus or --x11=xorg.

gitea-mirror commented

2026-05-05 08:37:46 -06:00

Author

Owner

@smitsohu commented on GitHub (Jan 14, 2020):

@mavrent
If you run

$ firejail firefox
...
Parent pid 8746, child pid 8747

then it should look like this in a second terminal (expect your user id in place of the 1000):

$ grep Uid /proc/8746/status
1000    1000    0       1000
$ grep Uid /proc/8747/status
1000    1000    1000    1000

@rusty-snake
If I join a sandbox and then check the uid in /proc/PID/status, I get

$ grep Uid /proc/8792/status
1000    0     0     0

In my understanding this is more a cosmetic problem. We should be able to fix it by switching the effective uid to the user right after the fork (in join.c).

@smitsohu commented on GitHub (Jan 14, 2020): @mavrent If you run ``` $ firejail firefox ... Parent pid 8746, child pid 8747 ``` then it should look like this in a second terminal (expect your user id in place of the `1000`): ``` $ grep Uid /proc/8746/status 1000 1000 0 1000 $ grep Uid /proc/8747/status 1000 1000 1000 1000 ``` @rusty-snake If I join a sandbox and then check the uid in /proc/PID/status, I get ``` $ grep Uid /proc/8792/status 1000 0 0 0 ``` In my understanding this is more a cosmetic problem. We should be able to fix it by switching the effective uid to the user right after the fork (in join.c).

gitea-mirror commented

2026-05-05 08:37:46 -06:00

Author

Owner

@smitsohu commented on GitHub (Jan 17, 2020):

@rusty-snake firejail sitting around as root should be gone with 1cfd33ed0e. At least if that process was started with the join option.

@smitsohu commented on GitHub (Jan 17, 2020): @rusty-snake firejail sitting around as root should be gone with 1cfd33ed0e097c56fafa9d747f41ac34fb9169f8. At least if that process was started with the `join` option.

gitea-mirror commented

2026-05-05 08:37:47 -06:00

Author

Owner

@mavrent commented on GitHub (Jan 30, 2020):

@smitsohu
https://imgur.com/onpODh1.png
[user@desktop 571703]$ grep Uid status
Uid: 1000 1000 1000 1000
[user@desktop 571703]$

So, the effective UID seems to be normal, but I've included the htop screenshot that makes it look like there's a problem.
Let me know if there's something else I can do while I have it like this, it took 2 weeks to happen again.

EDIT: Screenshot from the normal top utility shows both processes running as user.
https://i.imgur.com/FFfdhWd.png

Also, I just restarted htop and it's back to normal.

@mavrent commented on GitHub (Jan 30, 2020): @smitsohu https://imgur.com/onpODh1.png [user@desktop 571703]$ grep Uid status Uid: 1000 1000 1000 1000 [user@desktop 571703]$ So, the effective UID seems to be normal, but I've included the htop screenshot that makes it look like there's a problem. Let me know if there's something else I can do while I have it like this, it took 2 weeks to happen again. EDIT: Screenshot from the normal top utility shows both processes running as user. https://i.imgur.com/FFfdhWd.png Also, I just restarted htop and it's back to normal.

gitea-mirror commented

2026-05-05 08:37:47 -06:00

Author

Owner

@smitsohu commented on GitHub (Jan 31, 2020):

@mavrent Thanks!
It is a weird issue. Sadly I cannot reproduce it (yet).

@smitsohu commented on GitHub (Jan 31, 2020): @mavrent Thanks! It is a weird issue. Sadly I cannot reproduce it (yet).

gitea-mirror commented

2026-05-05 08:37:47 -06:00

Author

Owner

@smitsohu commented on GitHub (Feb 1, 2020):

Alright, now I can see it!

If I understand htop right, it determines the owner of the proc/PID directory in order to figure out the effective user id of a process. And what's important, this information seems to be cached.

I checked both the user ids in /proc/PID/status and directory ownership of /proc/PID, and everything is (my) user 1000. Still htop wants to tell me the process is running as root.

During start up, Firejail indeed switches repeatedly the effective user. This is nothing bad and necessary for it to do its job. So what probably happens is that htop picks up Firejail while it is still configuring the sandbox and temporarily runs as root. Then it ignores following user id changes and so will display root forever.

@smitsohu commented on GitHub (Feb 1, 2020): Alright, now I can see it! If I understand htop right, it determines the owner of the proc/PID directory in order to figure out the effective user id of a process. And what's important, this information seems to be cached. I checked both the user ids in /proc/PID/status and directory ownership of /proc/PID, and everything is (my) user `1000`. Still htop wants to tell me the process is running as root. During start up, Firejail indeed switches repeatedly the effective user. This is nothing bad and necessary for it to do its job. So what probably happens is that htop picks up Firejail while it is still configuring the sandbox and temporarily runs as root. Then it ignores following user id changes and so will display root forever.

Rows
Columns

[GH-ISSUE #3130] firejail randomly elevates itself from standard user to root #1964