[GH-ISSUE #1133] [discussion] allow to specify full path to the binary in private-bin #782

Closed
opened 2026-05-05 06:39:13 -06:00 by gitea-mirror · 1 comment
Owner

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

private-bin doesn't allow to specify full path to the binary, but only it's name:
Error: "/bin/env" is an invalid filename
But it can lead to issues like this:

$ firejail --join=tg ls /bin/env -l
lrwxrwxrwx 1 65534 65534 8 мар  7 23:48 /bin/env -> /bin/env

Here, it is happened because firejail copied env from /usr/bin, where it resides for compatibility while actually it is installed (like entire coreutils) to /bin.

And, mostly destructive: it can even be situation when it will copy the wrapper from /usr/local/bin (which have bigger priority than even /usr/bin), but not the target binary which the wrapper actually calls...

INB4: yes, it can (partially) be fixed by allowing to follow symlinks, but it:

  1. will cause #1129
  2. it can be situations, when user would like to directly specify which binary should be used (from less-priority PATH part, for example, or even custom wrapper)
Originally created by @msva on GitHub (Mar 7, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1133 `private-bin` doesn't allow to specify full path to the binary, but only it's name: ```Error: "/bin/env" is an invalid filename``` But it can lead to issues like this: ``` $ firejail --join=tg ls /bin/env -l lrwxrwxrwx 1 65534 65534 8 мар 7 23:48 /bin/env -> /bin/env ``` Here, it is happened because firejail copied `env` from `/usr/bin`, where it resides for compatibility while actually it is installed (like entire coreutils) to /bin. And, mostly ***destructive***: it can even be situation when it will copy the wrapper from `/usr/local/bin` (which have bigger priority than even `/usr/bin`), but not the target binary which the wrapper actually calls... INB4: yes, it can (partially) be fixed by allowing to follow symlinks, but it: 1) will cause #1129 2) it can be situations, when user would like to directly specify which binary should be used (from less-priority PATH part, for example, or even custom wrapper)
Author
Owner

@LaurentGH commented on GitHub (Aug 23, 2017):

Hello,
I faced the same problem with Ubuntu 16.04, where /usr/bin/which is a symlink to /bin/which. So, using "private-bin which" finds "which" in /usr/bin and adds the symlink to "which" in /bin mapped directory. The /bin directory thus contains a symlink named "which" pointing to "/bin/which" (itself). This creates a symlink loop, and does not work.
In order to solve this, I created a patch (attached), which allows to specify the full path, such as "private-bin /bin/which".
patch.txt

<!-- gh-comment-id:324357263 --> @LaurentGH commented on GitHub (Aug 23, 2017): Hello, I faced the same problem with Ubuntu 16.04, where /usr/bin/which is a symlink to /bin/which. So, using "private-bin which" finds "which" in /usr/bin and adds the symlink to "which" in /bin mapped directory. The /bin directory thus contains a symlink named "which" pointing to "/bin/which" (itself). This creates a symlink loop, and does not work. In order to solve this, I created a patch (attached), which allows to specify the full path, such as "private-bin /bin/which". [patch.txt](https://github.com/netblue30/firejail/files/1245800/patch.txt)
Sign in to join this conversation.
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#782
No description provided.