github-starred/firejail

Fork 0

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

lib #630

New issue

Closed

opened 2026-05-05 06:18:41 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 06:18:41 -06:00

Owner

Originally created by @valoq on GitHub (Nov 19, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/926

On debian testing mupdf fails to start (using the git version from today)
The reason is private-bin mupdf

When investigating why the private-bin restriction prevents mupdf from starting it turned out that
on debian stetch (testing) /usr/bin/mupdf is only a helper binary executing /usr/lib/mupdf/mupdf-x11

however adding mupdf-x11 or /usr/lib/mupdf/mupdf-x11 to the private-bin list does not work likely because /usr/lib is not in the usual PATH variable

when executing "firejail --profile=mymupdf.profile /usr/lib/mupdf/mupdf-x11 testfile.pdf" the private-bin has no effect and mupdf works

I suspect there might be more applications executing binaries in /usr/lib/ which will fail if private-bin is used

Is there any other solution except to remove private-bin from all application profiles that execute binaries in /usr/lib

Originally created by @valoq on GitHub (Nov 19, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/926 On debian testing mupdf fails to start (using the git version from today) The reason is private-bin mupdf When investigating why the private-bin restriction prevents mupdf from starting it turned out that on debian stetch (testing) /usr/bin/mupdf is only a helper binary executing /usr/lib/mupdf/mupdf-x11 however adding mupdf-x11 or /usr/lib/mupdf/mupdf-x11 to the private-bin list does not work likely because /usr/lib is not in the usual PATH variable when executing "firejail --profile=mymupdf.profile /usr/lib/mupdf/mupdf-x11 testfile.pdf" the private-bin has no effect and mupdf works I suspect there might be more applications executing binaries in /usr/lib/ which will fail if private-bin is used Is there any other solution except to remove private-bin from all application profiles that execute binaries in /usr/lib

gitea-mirror closed this issue

2026-05-05 06:18:43 -06:00

gitea-mirror commented

2026-05-05 06:18:45 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Nov 19, 2016):

That's weird. I use Libreoffice every so often, and I use it within firejail (profile is in my repo: https://github.com/chiraag-nataraj/firejail-profiles). Libreoffice's actual binary is in /usr/lib/libreoffice/program/soffice, yet it manages to run. (And yes, I use private-bin in my profile). Could this be purely an issue with mupdf? You're using the default profile, right?

[EDIT] You need to whitelist more things: sh, tempfile, and rm to be exact (maybe more - I shall keep investigating).

[EDIT2] Added a mupdf profile to my repo which works. Note: The profile only allows access to Downloads/ and Documents/ by default.

@chiraag-nataraj commented on GitHub (Nov 19, 2016): That's weird. I use Libreoffice every so often, and I use it within firejail (profile is in my repo: https://github.com/chiraag-nataraj/firejail-profiles). Libreoffice's actual binary is in /usr/lib/libreoffice/program/soffice, yet it manages to run. (And yes, I use private-bin in my profile). Could this be purely an issue with mupdf? You're using the default profile, right? [EDIT] You need to whitelist more things: `sh`, `tempfile`, and `rm` to be exact (maybe more - I shall keep investigating). [EDIT2] Added a mupdf profile to my repo which works. Note: The profile only allows access to Downloads/ and Documents/ by default.

gitea-mirror commented

2026-05-05 06:18:47 -06:00

Author

Owner

@valoq commented on GitHub (Nov 20, 2016):

Thanks for the info, this solved it. Seems like it was not a PATH issue after all.

I wonder why debain has changed mupdf to use those programs. On other distributions mupdf runs fine without them

By the way, alternatives and X11 are not needed in private-etc, at least I did not have any issues without them.

@valoq commented on GitHub (Nov 20, 2016): Thanks for the info, this solved it. Seems like it was not a PATH issue after all. I wonder why debain has changed mupdf to use those programs. On other distributions mupdf runs fine without them By the way, alternatives and X11 are not needed in private-etc, at least I did not have any issues without them.

gitea-mirror commented

2026-05-05 06:18:49 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Nov 20, 2016):

I whitelist them because that's where cursors are stored 😉 But yes, strictly speaking, they're not necessary xD

@chiraag-nataraj commented on GitHub (Nov 20, 2016): I whitelist them because that's where cursors are stored :wink: But yes, strictly speaking, they're not _necessary_ xD

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

No description provided.

Rows
Columns