github-starred/firejail

Fork 0

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

[GH-ISSUE #1129] [bug] Changed behaviour of private-bin (resulting in broken apps) #775

New issue

Closed

opened 2026-05-05 06:38:16 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 06:38:16 -06:00

Owner

Originally created by @msva on GitHub (Mar 5, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1129

Somewhere between git HEAD of 12.02.2017 and current git HEAD (too much commits to bisect 😢) there was a change in the code, that changed behaviour of private-bin key.

Since that moment, some applications with "bundled" libraries (almost any application made on electron, like atom, new skype, discord, and so on; proprietary games; some other proprietary software; and many more) become broken (this also affects the way like firecfg configures things (like /usr/local/bin/appname -> /usr/bin/firejail)).

Let's take slack application as example:

Originally it has /usr/bin/slack -> /usr/lib/slack/slack symlink.
And also it is linked to libnode.so library, which resides in /usr/lib/slack/.

Usually, likner, when ( starting an application ) and ( can't find libraries in "system" paths ), "falls back" to looking in the directory, where the binary resides.

Previously, firejail copied the target file into jail keeping it's original type (so, symlinks stayed symlinks, and that black magic worked).
firejail wasn't try to be smarter than it is, so linker dereferenced that symlinks by itself and, in case of slack, looked for libnode.so in /usr/lib/slack/, and succeeded.

But since some commit between dates specified above, firejail started to copy target as binary (i.e. started to dereference symlinks), and not keeping original type.
So, symlinks in private-bin become binary, and now linker tries to load libnode.so from /usr/bin (because it is nothing to dereference, so it takes /usr/bin as the path where binary resides), and, obviously, fails to load that libnode.so.

I don't know the reason why did you change this behaviour, so I can't advice a proper way to fix that.

Mostly simple way — will be to roll back to old behaviour, with keeping symlinks as symlinks. But it, probably, have some security issues.

The best way will be to pollute ld.so.conf, but it has some issues too:

it is not so obvious, where it should reside: on many linuxes it is usually /etc/ld.co.conf, but with some other libcs than glibc|musl|uClibc (like, maybe android) it can be another paths. So, tracking all the possible paths of ld.so.conf may become a pain in the ass.
when polluting jailed ld.so.conf, it is important to not just "copy content of external system ld.so.conf and concatenate it with dirname of the symlink", but firejail should also parse it's syntax (take include dirs and add them to whitelist)

Maybe it is some other ways, but I don't see them ATM.

Originally created by @msva on GitHub (Mar 5, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1129 Somewhere between git HEAD of 12.02.2017 and current git HEAD (too much commits to bisect 😢) there was a change in the code, that changed behaviour of private-bin key. Since that moment, some applications with "bundled" libraries (almost any application made on `electron`, like `atom`, new `skype`, discord, and so on; proprietary games; some other proprietary software; and many more) become broken (this also affects the way like `firecfg` configures things (like `/usr/local/bin/appname -> /usr/bin/firejail`)). Let's take `slack` application as example: Originally it has `/usr/bin/slack -> /usr/lib/slack/slack` symlink. And also it is linked to `libnode.so` library, which resides in `/usr/lib/slack/`. Usually, likner, when `(` starting an application `)` and `(` can't find libraries in "system" paths `)`, "falls back" to looking in the directory, where the binary resides. Previously, `firejail` copied the target file into jail keeping it's original type (so, symlinks stayed symlinks, and that black magic worked). `firejail` wasn't try to be smarter than it is, so linker dereferenced that symlinks by itself and, in case of `slack`, looked for `libnode.so` in `/usr/lib/slack/`, and succeeded. But since some commit between dates specified above, `firejail` started to copy target as binary (i.e. started to dereference symlinks), and not keeping original type. So, symlinks in private-bin become binary, and now linker tries to load `libnode.so` from `/usr/bin` (because it is nothing to dereference, so it takes `/usr/bin` as the path where binary resides), and, obviously, fails to load that `libnode.so`. I don't know the reason why did you change this behaviour, so I can't advice a proper way to fix that. Mostly simple way — will be to roll back to old behaviour, with keeping symlinks as symlinks. But it, probably, have some ***security issues***. The ***best*** way will be to pollute `ld.so.conf`, but it has some issues too: 1) it is not so obvious, where it should reside: on many linuxes it is usually `/etc/ld.co.conf`, but with some other `libc`s than `glibc|musl|uClibc` (like, maybe android) it can be another paths. So, tracking all the possible paths of ld.so.conf may become a pain in the ass. 2) when polluting jailed ld.so.conf, it is important to not just "copy content of external system ld.so.conf and concatenate it with dirname of the symlink", but `firejail` should also parse it's syntax (take `include` dirs and add them to whitelist) Maybe it is some other ways, but I don't see them ATM.

gitea-mirror

2026-05-05 06:38:16 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 06:38:22 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Mar 6, 2017):

I was experiencing this too! Looks like you beat me to the report. 😄

@Fred-Barclay commented on GitHub (Mar 6, 2017): I was experiencing this too! Looks like you beat me to the report. :smile:

gitea-mirror commented

2026-05-05 06:38:24 -06:00

Author

Owner

@msva commented on GitHub (Mar 7, 2017):

By the way, @netblue30, it affects even firefox:

$ sudo ln -s /usr/bin/firejail /usr/local/bin/firefox
$ firefox https://twitter.com/bobuk/status/838831958511796226
Could not find the Mozilla runtime.
$ ls -l /usr/bin/firefox
lrwxrwxrwx 1 root root 26 янв 31 20:19 /usr/bin/firefox -> /usr/lib64/firefox/firefox*
$ sudo rm /usr/local/bin/firefox
$ firejail /usr/lib64/firefox/firefox https://twitter.com/bobuk/status/838831958511796226
$

@msva commented on GitHub (Mar 7, 2017): By the way, @netblue30, it affects even firefox: ``` $ sudo ln -s /usr/bin/firejail /usr/local/bin/firefox $ firefox https://twitter.com/bobuk/status/838831958511796226 Could not find the Mozilla runtime. $ ls -l /usr/bin/firefox lrwxrwxrwx 1 root root 26 янв 31 20:19 /usr/bin/firefox -> /usr/lib64/firefox/firefox* $ sudo rm /usr/local/bin/firefox $ firejail /usr/lib64/firefox/firefox https://twitter.com/bobuk/status/838831958511796226 $ ```

gitea-mirror commented

2026-05-05 06:38:26 -06:00

Author

Owner

@netblue30 commented on GitHub (Mar 7, 2017):

Fixed!

I added support to follow links in --private-bin a few days ago, enabled by default. I modified the default to "disabled" - it can be controlled from /etc/firejail/firejail.config. Thanks for letting me know.

@netblue30 commented on GitHub (Mar 7, 2017): Fixed! I added support to follow links in --private-bin a few days ago, enabled by default. I modified the default to "disabled" - it can be controlled from /etc/firejail/firejail.config. Thanks for letting me know.

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

No description provided.

Rows
Columns