github-starred/firejail
2
0
Fork 0
mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00
Code Issues 531 Projects Packages Wiki Activity Actions 6

[GH-ISSUE #1927] firejail --list is empty, but firemon shows firejail processes #1288

New issue
Closed
opened 2026-05-05 07:48:07 -06:00 by gitea-mirror · 17 comments
gitea-mirror commented 2026-05-05 07:48:07 -06:00
Owner
Copy link

Originally created by @chiraag-nataraj on GitHub (May 5, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1927

This is really weird, and is probably a product (in some way) of hidepid=2.

  1. Mount /proc with hidepid=2 (my exact mount options are nosuid,nodev,noexec,hidepid=2,gid=107)
  2. Launch something through firejail: firejail firefox
  3. Verify that firejail is in fact running: sudo pidof firejail
  4. Verify that firemon will show the relevant processes: sudo firemon
  5. firejail --list, sudo firejail --list, firejail --tree, and sudo firejail --tree all show nothing.

This seems to happen both with the current release version (0.9.52) and the current development version (0.9.53).

Originally created by @chiraag-nataraj on GitHub (May 5, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/1927 This is really weird, and is probably a product (in some way) of `hidepid=2`. 1. Mount `/proc` with `hidepid=2` (my exact mount options are `nosuid,nodev,noexec,hidepid=2,gid=107`) 2. Launch something through `firejail`: `firejail firefox` 3. Verify that `firejail` is in fact running: `sudo pidof firejail` 4. Verify that `firemon` will show the relevant processes: `sudo firemon` 5. `firejail --list`, `sudo firejail --list`, `firejail --tree`, and `sudo firejail --tree` all show nothing. This seems to happen both with the current release version (0.9.52) and the current development version (0.9.53).
gitea-mirror commented 2026-05-05 07:48:12 -06:00
Author
Owner
Copy link

@SkewedZeppelin commented on GitHub (May 5, 2018):

So firejail --list should output Error: /proc is mounted hidepid, you would need to be root to run this command, but isn't?

sudo firecfg --list should work, but isn't?

<!-- gh-comment-id:386833097 --> @SkewedZeppelin commented on GitHub (May 5, 2018): So `firejail --list` should output `Error: /proc is mounted hidepid, you would need to be root to run this command`, but isn't? `sudo firecfg --list` should work, but isn't?
gitea-mirror commented 2026-05-05 07:48:13 -06:00
Author
Owner
Copy link

@chiraag-nataraj commented on GitHub (May 5, 2018):

So I expect firejail --list to be blank or give me an error, but I expect sudo firejail --list to give me the proper list. firemon works as expected (gives me the error as regular user and outputs the processes as root).

<!-- gh-comment-id:386833737 --> @chiraag-nataraj commented on GitHub (May 5, 2018): So I expect `firejail --list` to be blank or give me an error, but I expect `sudo firejail --list` to give me the proper list. `firemon` works as expected (gives me the error as regular user and outputs the processes as root).
gitea-mirror commented 2026-05-05 07:48:15 -06:00
Author
Owner
Copy link

@chiraag-nataraj commented on GitHub (May 5, 2018):

Currently investigating. Running firejail --debug --list seems to list the proper command to call (/usr/local/bin/firemon --list), but I'm not getting output from that command.

<!-- gh-comment-id:386835619 --> @chiraag-nataraj commented on GitHub (May 5, 2018): Currently investigating. Running `firejail --debug --list` seems to list the proper command to call (`/usr/local/bin/firemon --list`), but I'm not getting output from _that_ command.
gitea-mirror commented 2026-05-05 07:48:17 -06:00
Author
Owner
Copy link

@chiraag-nataraj commented on GitHub (May 5, 2018):

For some reason, firemon seems to act differently when called through firejail. Even if firemon doesn't have root permissions (which it needs with hidepid), it will try to enumerate everything when called through firejail, but not when called directly.

[edit]
I think I found an issue. When firemon is called through firejail, it thinks it has root privileges (i.e. getuid() returns 0) regardless of the calling user's UID. When firemon is invoked directly, getuid() returns the proper value. But I don't think this explains why sudo firejail --list doesn't work...going to continue digging. The issue seems to be with the pid_read() function, which seems to behave differently when called firemon is called through firejail (the PIDs which should have level 1 have level 0). Huh, the PID list itself seems to be different. This is really weird.

<!-- gh-comment-id:386841285 --> @chiraag-nataraj commented on GitHub (May 5, 2018): For some reason, `firemon` seems to act differently when called through `firejail`. Even if `firemon` doesn't have root permissions (which it needs with `hidepid`), it will try to enumerate everything when called through `firejail`, but not when called directly. [edit] I think I found an issue. When `firemon` is called through `firejail`, it thinks it has root privileges (i.e. `getuid()` returns 0) regardless of the calling user's UID. When `firemon` is invoked directly, `getuid()` returns the proper value. But I don't think this explains why `sudo firejail --list` doesn't work...going to continue digging. The issue seems to be with the `pid_read()` function, which seems to behave differently when called `firemon` is called through `firejail` (the PIDs which should have level 1 have level 0). Huh, the PID list itself seems to be different. This is really weird.
gitea-mirror commented 2026-05-05 07:48:19 -06:00
Author
Owner
Copy link

@Vincent43 commented on GitHub (May 5, 2018):

Does executing firejail --list as root (without sudo) has same effect?

<!-- gh-comment-id:386841776 --> @Vincent43 commented on GitHub (May 5, 2018): Does executing `firejail --list` as root (without sudo) has same effect?
gitea-mirror commented 2026-05-05 07:48:19 -06:00
Author
Owner
Copy link

@chiraag-nataraj commented on GitHub (May 5, 2018):

Yes. The PID list returned by pid_read is the same whether I run firejail --list as root or sudo firejail --list from my regular user. And it is definitely different from the actual PID list (which is return when I run firemon --list as root or through sudo). You can try it yourself by inserting printf("%i\n",pid) between pid_t pid = strtol(entry->d_name, &end, 10); and pid %= max_pids; in src/lib/pid.c.

<!-- gh-comment-id:386841849 --> @chiraag-nataraj commented on GitHub (May 5, 2018): Yes. The PID list returned by `pid_read` is the same whether I run `firejail --list` as root or `sudo firejail --list` from my regular user. And it is definitely different from the actual PID list (which is return when I run `firemon --list` as root or through sudo). You can try it yourself by inserting `printf("%i\n",pid)` between `pid_t pid = strtol(entry->d_name, &end, 10);` and `pid %= max_pids;` in `src/lib/pid.c`.
gitea-mirror commented 2026-05-05 07:48:20 -06:00
Author
Owner
Copy link

@Vincent43 commented on GitHub (May 5, 2018):

I guess firejail is always dropping some privileges or manipulating something as it always run as root regardless of sudo or not. It doesn't have to be a bad thing actually.

<!-- gh-comment-id:386842057 --> @Vincent43 commented on GitHub (May 5, 2018): I guess firejail is always dropping some privileges or manipulating something as it always run as root regardless of sudo or not. It doesn't have to be a bad thing actually.
gitea-mirror commented 2026-05-05 07:48:22 -06:00
Author
Owner
Copy link

@chiraag-nataraj commented on GitHub (May 5, 2018):

I suspect that is what is going on, since this seems to be a PID namespace of some sort. If so, we should deprecate firejail --list and just use firemon --list (probably same with --tree?).

<!-- gh-comment-id:386842114 --> @chiraag-nataraj commented on GitHub (May 5, 2018): I suspect that is what is going on, since this seems to be a PID namespace of some sort. If so, we should deprecate `firejail --list` and just use `firemon --list` (probably same with `--tree`?).
gitea-mirror commented 2026-05-05 07:48:23 -06:00
Author
Owner
Copy link

@chiraag-nataraj commented on GitHub (May 5, 2018):

But it's also weird that this is only happening with hidepid enabled...

<!-- gh-comment-id:386842125 --> @chiraag-nataraj commented on GitHub (May 5, 2018): But it's also weird that this is _only_ happening with `hidepid` enabled...
gitea-mirror commented 2026-05-05 07:48:23 -06:00
Author
Owner
Copy link

@Vincent43 commented on GitHub (May 5, 2018):

Without hidepid every user has the same view of processes (unless contained with firejail) so:
firemon, sudo firemon, firejail --tree have same effect.

<!-- gh-comment-id:386842230 --> @Vincent43 commented on GitHub (May 5, 2018): Without hidepid every user has the same view of processes (unless contained with firejail) so: `firemon`, `sudo firemon`, `firejail --tree` have same effect.
gitea-mirror commented 2026-05-05 07:48:25 -06:00
Author
Owner
Copy link

@chiraag-nataraj commented on GitHub (May 5, 2018):

Found it. The culprit was dropping capabilities before calling firemon.

<!-- gh-comment-id:386842457 --> @chiraag-nataraj commented on GitHub (May 5, 2018): Found it. The culprit was dropping capabilities before calling `firemon`.
gitea-mirror commented 2026-05-05 07:48:27 -06:00
Author
Owner
Copy link

@Vincent43 commented on GitHub (May 5, 2018):

I think the solution is to use firemon directly then.

<!-- gh-comment-id:386842623 --> @Vincent43 commented on GitHub (May 5, 2018): I think the solution is to use `firemon` directly then.
gitea-mirror commented 2026-05-05 07:48:28 -06:00
Author
Owner
Copy link

@chiraag-nataraj commented on GitHub (May 5, 2018):

Cool 👍 Maybe we should provide a warning if hidepid is enabled and --list or --tree is used?

<!-- gh-comment-id:386842665 --> @chiraag-nataraj commented on GitHub (May 5, 2018): Cool :+1: Maybe we should provide a warning if `hidepid` is enabled and `--list` or `--tree` is used?
gitea-mirror commented 2026-05-05 07:48:29 -06:00
Author
Owner
Copy link

@Vincent43 commented on GitHub (May 5, 2018):

It's interesting that when hidepid is enabled and user is in whitelisted group the behavior is quite the opposite:

$ firemon
Error: /proc is mounted hidepid, you would need to be root to run this command

$ firejail --list
1111:user::/usr/bin/firejail /usr/bin/firefox
<!-- gh-comment-id:386842943 --> @Vincent43 commented on GitHub (May 5, 2018): It's interesting that when hidepid is enabled and user is in whitelisted group the behavior is quite the opposite: ``` $ firemon Error: /proc is mounted hidepid, you would need to be root to run this command $ firejail --list 1111:user::/usr/bin/firejail /usr/bin/firefox ```
gitea-mirror commented 2026-05-05 07:48:31 -06:00
Author
Owner
Copy link

@chiraag-nataraj commented on GitHub (May 6, 2018):

Yeah, exactly. That's why I didn't see this bug/feature(?) until I removed my user from the whitelisted group.

<!-- gh-comment-id:386844788 --> @chiraag-nataraj commented on GitHub (May 6, 2018): Yeah, exactly. That's why I didn't see this bug/feature(?) until I removed my user from the whitelisted group.
gitea-mirror commented 2026-05-05 07:48:32 -06:00
Author
Owner
Copy link

@Vincent43 commented on GitHub (May 6, 2018):

What I presented above is also incorrect as firemon should check if user is in trusted group. When running through firejail, firemon thinks it's root and ignores hidepid.

So, as for now if hidepid is used and user is in trusted group they should use firejail --list or sudo firemon --list (but using sudo misses the point of being in trusted group), and when user isn't in trusted group they should use sudo firemon --list.

Adding proper checks to firemon would be valuable.

<!-- gh-comment-id:386881635 --> @Vincent43 commented on GitHub (May 6, 2018): What I presented above is also incorrect as firemon should check if user is in trusted group. When running through firejail, firemon thinks it's root and ignores hidepid. So, as for now if hidepid is used and user is in trusted group they should use `firejail --list` or `sudo firemon --list` (but using `sudo` misses the point of being in trusted group), and when user isn't in trusted group they should use `sudo firemon --list`. Adding proper checks to firemon would be valuable.
gitea-mirror commented 2026-05-05 07:48:33 -06:00
Author
Owner
Copy link

@netblue30 commented on GitHub (May 9, 2018):

Very cool bug!

Found it. The culprit was dropping capabilities before calling firemon.

I had to build a special capabilities filter for running under hidepid: 1576791f29

It's interesting that when hidepid is enabled and user is in whitelisted group the behavior is quite the opposite:
$ firemon
Error: /proc is mounted hidepid, you would need to be root to run this command

This is probably a second bug, thanks!

<!-- gh-comment-id:387776981 --> @netblue30 commented on GitHub (May 9, 2018): Very cool bug! > Found it. The culprit was dropping capabilities before calling firemon. I had to build a special capabilities filter for running under hidepid: https://github.com/netblue30/firejail/commit/1576791f29e8e9c83896fe1479e8bc099cca0d5a > It's interesting that when hidepid is enabled and user is in whitelisted group the behavior is quite the opposite: $ firemon Error: /proc is mounted hidepid, you would need to be root to run this command This is probably a second bug, thanks!
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
serialize_remounts_v2
landlock_v4
landlock
release-0.9.64
release-0.9.62
gitlab_ci
LTSbase
fred_ctests
docs
0.9.80
0.9.80-rc1
0.9.78
0.9.76
0.9.76-rc4
0.9.76-rc3
0.9.76-rc2
0.9.76-rc1
0.9.74
landlock-split
0.9.72
0.9.72rc1
0.9.70
0.9.68
0.9.68rc1
0.9.66
0.9.66rc1
0.9.64.4
0.9.64.2
0.9.64
0.9.64rc1
0.9.62.4
0.9.62.2
0.9.62
0.9.56.2-LTS
0.9.60
0.9.60-rc1
0.9.58.2
0.9.58
0.9.58-rc1
0.9.56-LTS-release
0.9.56-LTS
0.9.56
0.9.56-rc1
0.9.54
0.9.54-rc2
0.9.54-rc1
0.9.52
0.9.38.12
0.9.50
0.9.50-rc1
0.9.48
0.9.46
0.9.46-rc1
0.9.44.10
0.9.44.8
0.9.44.6
0.9.38.10
0.9.44.4
0.9.38.8
0.9.44.2
0.9.44
0.9.44-rc1
0.9.38.4
0.9.42
0.9.42-rc2
0.9.38.2
0.9.42-rc1
disable-globalcfg
0.9.40
0.9.40-rc1
0.9.38
0.9.38-rc1
0.9.36
0.9.36-rc1
0.9.34
0.9.34-rc1
0.9.32
0.9.32-rc1
0.9.30
0.9.30-rc1
Labels
Clear labels   
LTS merge

   
LTS merge

   
bug

   
bug

   
converted-to-discussion

   
doc-todo

   
documentation

   
duplicate

   
enhancement

   
file-transfer

   
firecfg

   
firejail-in-firejail

   
firetools

   
graphics

   
help wanted

   
information_old

   
installation

   
invalid

   
modif

   
moved

   
needinfo

   
networking

   
notabug

   
notourbug

   
old-version

   
overlayfs

   
packaging

   
profile-request

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
question_old

   
removal

   
runtime-permissions

   
sandbox-ipc

   
security

   
stale

   
wiki

   
wiki

   
wontfix

   
wordpress

   
workaround
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#1288
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?