github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #2875] Pidgin: fcitx input method switching only works with private-bin #1795

New issue

Closed

opened 2026-05-05 08:28:15 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 08:28:15 -06:00

Owner

Originally created by @ShadowsFriend on GitHub (Jul 29, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2875

I have encountered a pretty strange issue. With the default pidgin.profile, I cannot switch my input method in Pidgin using the fcitx input method framework. If I add private-bin pidgin and shell none (without shell none Pidgin does not start with execvp: No such file or directory when private-bin pidgin is used), however, everything works as expected. This surprised me quite a bit, as I was expecting private-bin to only restrict the access more and thus potentially break things and not fix them. As I lack the understanding to judge if this is the result of some unknown and potentially security impairing side-effects of private-bin, I decided to open an issue.

I am using firejail 0.9.60 on Gentoo.

Edit: Output of firejail --version:

firejail version 0.9.60

Compile time support:
        - AppArmor support is disabled
        - AppImage support is enabled
        - chroot support is enabled
        - file and directory whitelisting support is enabled
        - file transfer support is enabled
        - networking support is enabled
        - overlayfs support is enabled
        - private-home support is enabled
        - seccomp-bpf support is enabled
        - user namespace support is enabled
        - X11 sandboxing support is enabled

Originally created by @ShadowsFriend on GitHub (Jul 29, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2875 I have encountered a pretty strange issue. With the default pidgin.profile, I cannot switch my input method in Pidgin using the fcitx input method framework. If I add `private-bin pidgin` and `shell none` (without `shell none` Pidgin does not start with `execvp: No such file or directory` when `private-bin pidgin` is used), however, everything works as expected. This surprised me quite a bit, as I was expecting `private-bin` to only restrict the access more and thus potentially break things and not fix them. As I lack the understanding to judge if this is the result of some unknown and potentially security impairing side-effects of `private-bin`, I decided to open an issue. I am using firejail 0.9.60 on Gentoo. Edit: Output of `firejail --version`: ``` firejail version 0.9.60 Compile time support: - AppArmor support is disabled - AppImage support is enabled - chroot support is enabled - file and directory whitelisting support is enabled - file transfer support is enabled - networking support is enabled - overlayfs support is enabled - private-home support is enabled - seccomp-bpf support is enabled - user namespace support is enabled - X11 sandboxing support is enabled ```

gitea-mirror closed this issue

2026-05-05 08:28:16 -06:00

gitea-mirror commented

2026-05-05 08:28:18 -06:00

Author

Owner

@rusty-snake commented on GitHub (Aug 24, 2019):

It looks like nobody really has an idea and write something. I'm not using fcitx so I can't realy help, but two questions.

Also with --noprofile? (firejail --noprofile --private-bin=bash,pidgin,... pidgin)
Is only pidgin affected?

potentially security impairing side-effects of private-bin

There shouldn't be any.

A miserable program could have something like this. consider this: program abc has a second binary abc-auth which check if the current user/process is allowed to use a feature in abc. But abc is programed ~~like systemd~~ 🙊 ugly , if the auth binary isn't reachable it grands full permissions.

@rusty-snake commented on GitHub (Aug 24, 2019): It looks like nobody really has an idea and write something. I'm not using fcitx so I can't realy help, but two questions. 1. Also with `--noprofile`? (`firejail --noprofile --private-bin=bash,pidgin,... pidgin`) 2. Is only pidgin affected? > potentially security impairing side-effects of private-bin There shouldn't be any. A miserable program could have something like this. consider this: program abc has a second binary abc-auth which check if the current user/process is allowed to use a feature in abc. But abc is programed ~like systemd~ :speak_no_evil: ugly , if the auth binary isn't reachable it grands full permissions.

gitea-mirror commented

2026-05-05 08:28:18 -06:00

Author

Owner

@ShadowsFriend commented on GitHub (Aug 25, 2019):

I have only experienced this issue with Pidgin. Obviously, the input method itself does not work with profiles that include "nodbus" unless "ignore nodbus" is added. This is totally expected and unrelated to the issue with Pidgin, though.

To answer the second question: input method switching works when I start Pidgin with firejail --noprofile pidgin but Warning: an existing sandbox was detected. /usr/bin/pidgin will run without any additional sandboxing features is printed to the console, which probably means the result of it working in this case is worthless. It also works with firejail --noprofile --shell=none --private-bin=pidgin pidgin and no warning is printed in that case. With firejail --noprofile --private-bin=pidgin,zsh pidgin it does also work (I use zsh). And now it gets funny: with firejail --noprofile --private-bin=pidgin,bash,zsh pidgin it does not work.
In summary, as soon as there is access to bash from inside the sandbox (either by starting Pidgin without private-bin or by explicitly including bash in private-bin) the input method switching stops working.

@ShadowsFriend commented on GitHub (Aug 25, 2019): I have only experienced this issue with Pidgin. Obviously, the input method itself does not work with profiles that include "nodbus" unless "ignore nodbus" is added. This is totally expected and unrelated to the issue with Pidgin, though. To answer the second question: input method switching works when I start Pidgin with `firejail --noprofile pidgin` but `Warning: an existing sandbox was detected. /usr/bin/pidgin will run without any additional sandboxing features` is printed to the console, which probably means the result of it working in this case is worthless. It also works with `firejail --noprofile --shell=none --private-bin=pidgin pidgin` and no warning is printed in that case. With `firejail --noprofile --private-bin=pidgin,zsh pidgin` it does also work (I use zsh). And now it gets funny: with `firejail --noprofile --private-bin=pidgin,bash,zsh pidgin` it does not work. In summary, as soon as there is access to bash from inside the sandbox (either by starting Pidgin without private-bin or by explicitly including bash in private-bin) the input method switching stops working.

gitea-mirror commented

2026-05-05 08:28:19 -06:00

Author

Owner

@rusty-snake commented on GitHub (Aug 25, 2019):

😄 😆 😳 😜 😬 😕 😰 😂 😱 😫 😵 🙈 🙉 ❓ ⚠️ ⁉️ ‼️ 🙃 🦄

???!

@rusty-snake commented on GitHub (Aug 25, 2019): :smile: :laughing: :flushed: :stuck_out_tongue_winking_eye: :grimacing: :confused: :cold_sweat: :joy: :scream: :tired_face: :dizzy_face: :see_no_evil: :hear_no_evil: :question: :warning: :interrobang: :bangbang: :upside_down_face: :unicorn: # ???!

gitea-mirror commented

2026-05-05 08:28:19 -06:00

Author

Owner

@smitsohu commented on GitHub (Aug 25, 2019):

In summary, as soon as there is access to bash from inside the sandbox (either by starting Pidgin without private-bin or by explicitly including bash in private-bin) the input method switching stops working.

Possibly they implemented a fallback path if no bash can be found... maybe some binaries are missing to get it working with bash present. If you want to dig deeper, one place to start could be observing the output of sudo firemon while switching the input method.

But anyway, having no shell available inside the sandbox is good. Usually it means an attacker has to bring his own shell, it is one more hoop he has to jump through in order to be successful.

@smitsohu commented on GitHub (Aug 25, 2019): > In summary, as soon as there is access to bash from inside the sandbox (either by starting Pidgin without private-bin or by explicitly including bash in private-bin) the input method switching stops working. Possibly they implemented a fallback path if no bash can be found... maybe some binaries are missing to get it working with bash present. If you want to dig deeper, one place to start could be observing the output of `sudo firemon` while switching the input method. But anyway, having no shell available inside the sandbox is _good_. Usually it means an attacker has to bring his own shell, it is one more hoop he has to jump through in order to be successful.

gitea-mirror commented

2026-05-05 08:28:20 -06:00

Author

Owner

@rusty-snake commented on GitHub (Oct 13, 2019):

I'm closing here due to inactivity, please fell free to reopen if you still have this issue.

@rusty-snake commented on GitHub (Oct 13, 2019): I'm closing here due to inactivity, please fell free to reopen if you still have this issue.

No milestone

No project

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#1795

No description provided.

Rows
Columns