github-starred/firejail

Fork 0

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

[GH-ISSUE #6762] wine: blacklisting python prevents gstreamer initialization #3361

New issue

Closed

opened 2026-05-05 09:56:35 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-05-05 09:56:35 -06:00

Owner

Originally created by @kolAflash on GitHub (May 29, 2025).
Original GitHub issue: https://github.com/netblue30/firejail/issues/6762

Description

If ~/.cache/gstreamer-1.0/ is empty, /usr/lib/python3* is needed to initialize it. But --profile=wine blacklists /usr/lib/python3*.

Wine needs gstreamer for example in the case of EpicGamesLauncherInstaller.msi (2025-05-29).

Steps to Reproduce

Steps to reproduce the behavior

copy EpicInstaller-18.5.0.msi to ~/.wine/drive_c/
firejail --profile=wine --whitelist="${HOME}"/.wine wine msiexec /i 'C:\\EpicInstaller-18.5.0.msi' /q
firejail --profile=wine --whitelist="${HOME}"/.wine wine 'C:\\Program Files (x86)\\Epic Games\\Launcher\\Portal\\Binaries\\Win32\\EpicGamesLauncher.exe'

Expected behavior

Epic Games Launcher login screen should show up.

Actual behavior

Epic Games Launcher is stuck loading the login screen.

Additional context

Workaround: Add --noblacklist=/usr/lib/python3*

QUESTION:
I'm asking myself why interpreters and anything under /usr/ is blacklisted at all. This directory contains just files available from the Internet. There can be no information leak. And if an evil program needs an interpreter or anything else from /usr/, it can just download that from the Internet itself and place them in a writeable directory. And even evil programs without Internet access could carry a Python interpreter with them, in fact many programs do so.
When thinking about the 3 hours it took me to figure this problem out, then I'm thinking:
Why block anything below /usr/ at all for most applications, including Wine?

Environment

Name/version/arch of the Linux kernel (uname -srm): Linux 6.12.27-amd64 x86_64
Name/version of the Linux distribution: Debian-13
Name/version of the relevant program(s)/package(s): gstreamer-1.26.1 by Debian-13, Wine-Devel-10.8 from https://gitlab.winehq.org/wine/wine/-/wikis/Debian-Ubuntu
Version of Firejail (firejail --version): 0.9.74

Checklist

The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it).
I can reproduce the issue without custom modifications (e.g. globals.local).
The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
The profile (and redirect profile if exists) hasn't already been fixed upstream.
- wine: 072c15b8bf/etc/profile-m-z/wine.profile (L20)
- disable-interpreters: 072c15b8bf/etc/inc/disable-interpreters.inc (L76)
I have performed a short search for similar issues (to avoid opening a duplicate).
- I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.
I used --profile=PROFILENAME to set the right profile. (Only relevant for AppImages)

Originally created by @kolAflash on GitHub (May 29, 2025). Original GitHub issue: https://github.com/netblue30/firejail/issues/6762 ### Description If `~/.cache/gstreamer-1.0/` is empty, `/usr/lib/python3*` is needed to initialize it. But `--profile=wine` blacklists `/usr/lib/python3*`. Wine needs gstreamer for example in the case of [EpicGamesLauncherInstaller.msi](https://launcher-public-service-prod06.ol.epicgames.com/launcher/api/installer/download/EpicGamesLauncherInstaller.msi) (2025-05-29). ### Steps to Reproduce _Steps to reproduce the behavior_ 1. copy `EpicInstaller-18.5.0.msi` to `~/.wine/drive_c/` 2. `firejail --profile=wine --whitelist="${HOME}"/.wine wine msiexec /i 'C:\\EpicInstaller-18.5.0.msi' /q` 3. `firejail --profile=wine --whitelist="${HOME}"/.wine wine 'C:\\Program Files (x86)\\Epic Games\\Launcher\\Portal\\Binaries\\Win32\\EpicGamesLauncher.exe'` ### Expected behavior Epic Games Launcher login screen should show up. ### Actual behavior Epic Games Launcher is stuck loading the login screen. ### Additional context Workaround: Add `--noblacklist=/usr/lib/python3*` QUESTION: I'm asking myself why interpreters and anything under `/usr/` is blacklisted at all. This directory contains just files available from the Internet. There can be no information leak. And if an evil program needs an interpreter or anything else from `/usr/`, it can just download that from the Internet itself and place them in a writeable directory. And even evil programs without Internet access could carry a Python interpreter with them, in fact many programs do so. When thinking about the 3 hours it took me to figure this problem out, then I'm thinking: Why block anything below `/usr/` at all for most applications, including Wine? ### Environment - Name/version/arch of the Linux kernel (`uname -srm`): `Linux 6.12.27-amd64 x86_64` - Name/version of the Linux distribution: `Debian-13` - Name/version of the relevant program(s)/package(s): `gstreamer-1.26.1` by Debian-13, Wine-Devel-10.8 from https://gitlab.winehq.org/wine/wine/-/wikis/Debian-Ubuntu - Version of Firejail (`firejail --version`): `0.9.74` ### Checklist  - [x] The issues is caused by firejail (i.e. running the program by path (e.g. `/usr/bin/vlc`) "fixes" it). - [x] I can reproduce the issue without custom modifications (e.g. globals.local). - [x] The program has a profile. (If not, request one in `https://github.com/netblue30/firejail/issues/1139`) - [x] The profile (and redirect profile if exists) hasn't already been fixed [upstream](https://github.com/netblue30/firejail/tree/master/etc). - wine: https://github.com/netblue30/firejail/blob/072c15b8bfc1eca0368071c3d798b29459686c04/etc/profile-m-z/wine.profile#L20 - disable-interpreters: https://github.com/netblue30/firejail/blob/072c15b8bfc1eca0368071c3d798b29459686c04/etc/inc/disable-interpreters.inc#L76 - [x] I have performed a short search for similar issues (to avoid opening a duplicate). - [x] I'm aware of `browser-allow-drm yes`/`browser-disable-u2f no` in `firejail.config` to allow DRM/U2F in browsers. - [x] I used `--profile=PROFILENAME` to set the right profile. (Only relevant for AppImages)

gitea-mirror

2026-05-05 09:56:35 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 09:56:37 -06:00

Author

Owner

@kmk3 commented on GitHub (May 30, 2025):

Should be fixed by:

#6763

QUESTION: I'm asking myself why interpreters and anything under /usr/ is
blacklisted at all. This directory contains just files available from the
Internet. There can be no information leak. And if an evil program needs an
interpreter or anything else from /usr/, it can just download that from the
Internet itself and place them in a writeable directory. And even evil
programs without Internet access could carry a Python interpreter with them,
in fact many programs do so. When thinking about the 3 hours it took me to
figure this problem out, then I'm thinking: Why block anything below /usr/
at all for most applications, including Wine?

Note that for the most part firejail does not try to protect against outright
evil/hostile programs, but instead tries limit the damage that presumably good
programs can do if something goes wrong.

Also, many programs are compiled and do not need access to an interpreter (or
the internet), in which case there is usually no point in allowing that.

Otherwise, I think the idea is that it's easier/less risky to simply run a
malicious command vs needing to download an entire shell (or another program)
before doing so.

In any case, this is a valid point, so feel free to open a dedicated discussion
about it.

Edit: Discussion:

#6764

@kmk3 commented on GitHub (May 30, 2025): Should be fixed by: * #6763 > QUESTION: I'm asking myself why interpreters and anything under `/usr/` is > blacklisted at all. This directory contains just files available from the > Internet. There can be no information leak. And if an evil program needs an > interpreter or anything else from `/usr/`, it can just download that from the > Internet itself and place them in a writeable directory. And even evil > programs without Internet access could carry a Python interpreter with them, > in fact many programs do so. When thinking about the 3 hours it took me to > figure this problem out, then I'm thinking: Why block anything below `/usr/` > at all for most applications, including Wine? Note that for the most part firejail does not try to protect against outright evil/hostile programs, but instead tries limit the damage that presumably good programs can do if something goes wrong. Also, many programs are compiled and do not need access to an interpreter (or the internet), in which case there is usually no point in allowing that. Otherwise, I think the idea is that it's easier/less risky to simply run a malicious command vs needing to download an entire shell (or another program) before doing so. In any case, this is a valid point, so feel free to open a dedicated discussion about it. Edit: Discussion: * #6764

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

No description provided.

Rows
Columns