mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #6906] File dialog crashes (gdk-pixbuf2 + glycin + bwrap) #3412
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#3412
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @myrslint on GitHub (Sep 21, 2025).
Original GitHub issue: https://github.com/netblue30/firejail/issues/6906
Description
Applications that use glycin 2.0.0 or later via gdk-pixbuf2 (examples: Firefox, Thunderbird, GIMP) crash
The library glycin provides a set of "safe" image format loaders to gdk-pixbuf2, another library which is widely used in GTK-based applications for loading images.
As of gdk-pixbuf2 2.44.1 the calls to glycin loaders are wrapped in bubblewrap (bwrap).
Steps to Reproduce
Thunderbird similarly crashes if one tries to open a file for any purpose. GIMP does not launch at all, if sandboxed with firejail..
Expected behavior
These applications work inside firejail sandbox as they did before.
Actual behavior
The mentioned applications crash.
Behavior without a profile
What changed calling
LC_ALL=C firejail --noprofile /path/to/programin aterminal?
Firefox, and the other applications, don't crash.
Additional context
This ties into the as-yet unsolved problem of running applications that try to use bwrap inside the firejail sandbox. The applications doing this used to be relatively few and perhaps considered of lower impact e.g., Foliate. Now, it is Firefox, via gdk-pixbuf2. Web browsers are probably the main type of application one would want to use inside a firejail sandbox.
Environment
uname -srm):Linux 6.16.8-arch1-1 x86_64mesa 1:24.3.3-2"): Firefox 143.0.1
firejail --version): firejail-git from AUR,0.9.76.r88.gd0c89ae81-1was compiled (
git rev-parse HEAD): gd0c89ae81Checklist
/usr/bin/vlc) "fixes" it).https://github.com/netblue30/firejail/issues/1139)browser-allow-drm yes/browser-disable-u2f noinfirejail.configto allow DRM/U2F in browsers.--profile=PROFILENAMEto set the right profile. (Only relevant for AppImages)Log
After adding the following lines to
firefox.local:The relevant error message becomes:
@myrslint commented on GitHub (Sep 21, 2025):
In the specific case of Firefox, adding the following to
firefox.localprevents crashes:@myrslint commented on GitHub (Sep 22, 2025):
I believe the
noblacklistdirectives and change of seccomp filter are also necessary in each profile to ensure correct operation of applications that invoke bwrap this way. So far I have tested them with Firefox and Thunderbird.@kmk3 commented on GitHub (Sep 22, 2025):
@myrslint
Thanks for all the details.
Yes, I created a PR just for the most straightforward change (#6907).
I'm not sure of a good way to fully fix this since it seems like the issue
could affect dozens of profiles.
Ideally there would be a way for bwrap to detect an existing sandbox (maybe
with an environment variable) and warn instead of erroring out.
Related:
@rusty-snake commented on GitHub (Sep 22, 2025):
Which is #3647 [EDIT: @kmk3 was faster]
@rusty-snake commented on GitHub (Sep 22, 2025):
There is
container=. However this would be the job of the call of bwrap (e.g. gdk/webkit/...) and not bwrap itself.@myrslint commented on GitHub (Sep 22, 2025):
At the moment, it seems Firefox works fine without patching firejail with the code changes listed at #3647. Only the additional directives in the profile are needed.
@rusty-snake commented on GitHub (Sep 22, 2025):
May depend on the environment. On the otherhand the commandline in OP does not list
--proc.@myrslint commented on GitHub (Sep 22, 2025):
Some hints as to what kind of minimum access is required for bwrap in the general case may be found at apparmor.d abstractions/common/bwrap.
@kmille commented on GitHub (Sep 24, 2025):
I have the same issue with signal-desktop and ristretto
@elmodor commented on GitHub (Sep 27, 2025):
I have the same issue but noticed that some programs require only the whitelist, or the noblacklist, or both while other crash if they are present. I am talking about those:
whitelistandnoblacklistin order for the download popup to workwhitelistornoblacklistare present. Both have to be absent for it to worknoblacklistto work. Shows an empty window if thewhitelistis present, so it has to be absentOn Arch 6.16.8-arch3-1, glycin 2.0.0-5, gdk-pixbuf2 2.44.2-1, firejail 0.9.76
@dev-random42 commented on GitHub (Sep 28, 2025):
I tried the additions to firefox.local as in https://github.com/netblue30/firejail/issues/6906#issuecomment-3316349578, but Firefox still crashes. The close/maximize/minimize buttons dont show an icon.
Is there another workaround?
On Arch Linux 6.16.8-zen3-1-zen x86_64
gdk-pixbuf2 2.44.2-1
glycin 2.0.2-1
@myrslint commented on GitHub (Sep 28, 2025):
First of all, update your Arch Linux (pacman -Syu) and reboot. Your versions of gdk-pixbuf2 and glycin are quite a bit behind the latest. Both packages have received important updates, including Arch-specific patches, in the last few days. If you still get crashes after that you may be facing a new, different problem.Bear in mind that glycin triggers a different bug, on machines with AMD GPUs (including iGPU), which has also been patched in these new versions of glycin shipped by Arch Linux. You can follow the discussion here: https://gitlab.freedesktop.org/drm/amd/-/issues/4568
Edit: The first paragraph is incorrect. Your versions are up to date.
@BlueMax commented on GitHub (Sep 28, 2025):
https://github.com/netblue30/firejail/issues/6906#issuecomment-3316349578 crashes here as well (log) on Intel cpu.
@myrslint commented on GitHub (Sep 28, 2025):
With an Intel CPU and NVIDIA GPU, the other bug does not seem to be relevant. It might help to also post the full contents of your
firefox.local. The error in the log you have posted looks like what you would get when Firefox is not allowed to execute bwrap.@myrslint commented on GitHub (Sep 28, 2025):
@dev-random42 and @BlueMax, this pkgrel 2 Arch Linux build of GTK3 is fresh off the presses, and it may solve your issue independent of firejail.
@BlueMax commented on GitHub (Sep 29, 2025):
Neither the new
GTK3nor thefirefox.localhelps. Myfirefox.localis exactly https://github.com/netblue30/firejail/issues/6906#issuecomment-3316349578. I've removed any otherglobal.localchanges andenvvariables from firefox. Also tested on new/blank firefox profile.@myrslint commented on GitHub (Sep 29, 2025):
Does Firefox run fine without firejail?
@BlueMax commented on GitHub (Sep 29, 2025):
Yes, works properly without firejail.
@myrslint commented on GitHub (Sep 29, 2025):
It is worth trying with firejail-git from AUR as well. I have that package installed, not the release version of official Arch repositories. There may be other profile changes since the last release which impact Firefox.
@BlueMax commented on GitHub (Sep 29, 2025):
firejail-gitdoesn't help either.There are no errors in journalctl. There were some
apparmor/mountdenials but even after granting them withignore seccomp !chroot,!mountthere was no improvement.Currently i'm using gdk-pixbuf2-noglycin as a workaround that doesn't need any
firefox.localpatches at all.@myrslint commented on GitHub (Sep 29, 2025):
Yes, that AUR package turns the clock back to before the introduction of glycin into gdk-pixbuf2.
Do you also have AppArmor active (
aa-enabledreturnsYes)? Are any profiles loaded, other than the default one which does nothing, for Firefox?@kinoegit commented on GitHub (Sep 29, 2025):
I tried that replacement too but without success: apps kept crashing! Would you mind to tell me how you replaced gdk-pixbuf2 (e.g. marking --asexplicit then install gdk-pixbuf2-noglycin?) How does gdk-pixbuf2-noglycin load icon/images? Do I need another loader?
@lordkitsuna commented on GitHub (Sep 29, 2025):
So i also ran into this issue, and the fix from previous message was not working for me. I do use a hardened custom profile and after testing taking options out one at a time i found that it will still crash with
#private-bin basename,bash,cat,dirname,expr,false,firefox,firefox-wayland,getenforce,ln,mkdir,pidof,restorecon,rm,rmdir,sed,sh,tclsh,true,unameoption so i assume there is something it needs to call. perhaps bubblewrap itself i am not sure if i can figure it out ill update my post@BlueMax commented on GitHub (Sep 29, 2025):
Yes
No.
I just installed/replaced it via
yay.Edit: I've noticed though after restart that *.svg icons are missing on desktop and default XFCE icons are wrong/different (not my theme,
delft darkest). Taskbar is not showing icons at all.The price is too high. I will go back to glycin.
@kinoegit commented on GitHub (Sep 30, 2025):
Keeping it as it is: firejail+ glycin <2.0.0 + gdk-pixbuf2 <2.44.1 doesn't come cheap as well -> missing icons in window frames and crashes when trying to download-- no low price at all.
@myrslint commented on GitHub (Sep 30, 2025):
During this adaptation period, it may serve users of Arch Linux well to update often. There have been some repository changes, staged first in testing, related to this issue everyday for a few days now. There are legacy glycin packages,
glycin1(for GTK3) andglycin1-gtk4(for GTK4), available in the official repositories now. These may solve your problems while the rough corners of the new versions being smoothed out.@kinoegit commented on GitHub (Sep 30, 2025):
In Arch repositories:
glycin
glycin-gtk4
glycin1
glycin1-gtk4
among other things its a bit confusing for me because glycin doesn't conflict with glycin1. Installed both but problems persist: apps keep crashing, lack of icons etc
@BlueMax commented on GitHub (Sep 30, 2025):
Looks like
apparmoris blockingbwrapcompletely.This works here:
Below are some
apparmorrules i logged/created withaa-logprofto see if i can fix it otherwise but there are too many (to be exceptions). I guess this should be handled by Firejail/apparmor instead. I'm wondering why this happens on my side only (and not for other people). Do i need an apparmorbwrapprofile in/etc/apparmor.d/or something? I've installedapparmor.d-gitbut it didn't help.@myrslint commented on GitHub (Sep 30, 2025):
On a desktop-oriented installation of Arch Linux, if you are not using the profiles from apparmor.d project (available as an AUR package) and willing to deal with the complexities those bring, AppArmor is much more trouble than it's worth. The default profiles do next to nothing but can interfere with legitimate activity.
My advice is to disable AppArmor altogether. This involves not loading the LSM at boot if you have an
lsm=kernel command line configured (e.g., in/etc/default/grub) and disablingapparmor.service.Attending to the actually useful profiles in apparmor.d so that they work for your specific use cases is a lot of work. It should be a conscious decision you make and you should be prepared to carefully read the documentation and the provided profiles to make sense of things.
@BlueMax commented on GitHub (Sep 30, 2025):
I've just installed AppArmor for Firejail. I'm not loading any profiles or services (beside firejail-default). I thought Firejail would generate/replace it's own per-app specific AppArmor rules or at least being of benefit for Firefox.
Firefox itself seems covered by Firejail/AppArmor. Maybe additional Firejail/AppArmor/bwrap rules are currently WIP.
Edit:
firefox-common.profileexplicitly setsapparmorso it must be handled by Firejail or removed. I will try to achieve a full bwrap ruleset for AppArmor. A dynamic per-profile AppArmor ruleset selection in Firejail would be useful.@gcb commented on GitHub (Oct 1, 2025):
i see the only place where this was addressed before was loupe profile
6c91074fc9@gcb commented on GitHub (Oct 1, 2025):
Thanks so much for investigating this whole issue!
The workaround to prevent crashes on file upload only, don't need seccomp changes, can be only this:
(i don't use many gtk applications nowadays, but this seems to have solved the few we use at the office)
@kinoegit commented on GitHub (Oct 1, 2025):
Could you give me a hint how this is solving the glycin problem? What am i missing here? I tried with both pkgs: legacy glycin1 and glycin without success: crashes are still occuring. Librewolf/ firefox is GTK3 isn't it?
seems to make no difference here w/ librewolf
@myrslint commented on GitHub (Oct 1, 2025):
Yes, they are GTK3 applications (with some caveats that are unimportant here). It seems glycin1 (the legacy package) is only required and/or used by Fractal (the Matrix protocol client). If you don't use Fractal, you can uninstall that.
Librewolf and Firefox use different Firejail profiles. If you created a
firefox.localfile under your user home directory's.config/firejaildirectory, it does not apply when Librewolf is being run under Firejail.Do Firefox and Librewolf run fine without Firejail?
Do you use any access control and/or sandbox other than Firejail?
Is AppArmor disabled or still active, as per default, on your Arch Linux install?
What messages do you see during a regular launch and subsequent crash of Firefox from a terminal?
Someone may be able to provide more specific advice if you provide more details of the problem you are facing.
@kinoegit commented on GitHub (Oct 1, 2025):
--> my librewolf.local:
EDIT: I also tried:
--> Yes they do. Downloads and icons are fine.
--> Generally I do use bwrap on other apps
--> AppArmor is disabled
Thanks a lot for helping!
@BlueMax commented on GitHub (Oct 2, 2025):
For reference:
AppArmor companion ruleset
@BlueMax commented on GitHub (Oct 2, 2025):
@kinoegit:
Do not split the cmds (yet). Paste https://github.com/netblue30/firejail/issues/6906#issuecomment-3316349578 exactly into
librewolf.localand post the full terminal output. Do not omit the seccomp lines.@kinoegit commented on GitHub (Oct 3, 2025):
@BlueMax many thanks! that fixed it. Don't know why I omitted the seccomp lines before...
@kinoegit commented on GitHub (Oct 4, 2025):
Fix for firejailed Librewolf (FF fork) is not the solution for Brave (Chromium fork). Though firejailed brave does not crash when trying to download anything (e.g. right click- service menu- save target under... /save image) but it does nothing- not even a complaint in the logs, nor in journalctl nor in firejail --debug!
brave.local:
Ctl+c images and paste them e.g. in a LO document is possible with or without the last 6 lines
@merdely commented on GitHub (Oct 4, 2025):
For me on Arch Linux, "noblacklist /usr/bin/bwrap" did not work, but "noblacklist ${PATH}/bwrap" does. The rest of the suggested additions to firefox.local work unchanged.
@kinoegit commented on GitHub (Oct 4, 2025):
Thanks for hinting, but it didn't change braves faulty behaviour.
@kinoegit commented on GitHub (Oct 4, 2025):
The same applies to Mullvad-browser but with the following, well known log entry:
Gtk:ERROR:../gtk/gtk/gtkiconhelper.c:495:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load .......despite the mullvad-browser.local:
@Daystar1998 commented on GitHub (Oct 6, 2025):
Profiles using private-bin will need to add bwrap to the list
@rsramkis commented on GitHub (Oct 6, 2025):
I've been trying to launch the Arch Linux native (non flatpak) version of Firefox 143.0.4 and it is still crashing with the following error:
I am using these settings in my firefox.local file:
Assuming my errors means I am missing something. I would like to get some feedback on how I might need to change my local file settings while a final approach is decided. Thank you.
@myrslint commented on GitHub (Oct 6, 2025):
Did you already try with
noblacklist /usr/bin/bwrapand then decide to comment it out to use the other form?@rsramkis commented on GitHub (Oct 6, 2025):
I tried with these setting individually and firefox failed to start:
My initial thoughts is this error:
What is it trying to do when loading pixbuf from icon theme located under usr/share/icons/Qogir-dark?
@kinoegit commented on GitHub (Oct 6, 2025):
Crashing mullvad-browser (FF) with an error log entry that i didn't observe before:
mullvad-browser-log.pdf
@myrslint commented on GitHub (Oct 6, 2025):
It is trying to execute
bwrapas a child process to wrap the image loader and failing to do so. The failure to load the image file is a result of that. As you can see on the first post of this issue this was the error I faced early on but allowing the execution ofbwrapseemed to resolve that. That is not happening in your case. You can attempt troubleshooting by trying to run bash under the firefox profile e.g.firejail --profile=/etc/firejail/firefox.profile bash. This should let you poke around a little to see what might be missing.@rsramkis commented on GitHub (Oct 6, 2025):
This is what I can see when I run the bash command:
@BlueMax commented on GitHub (Oct 6, 2025):
@rsramkis:
What kernel? Is this real Arch or derivate (CachyOS, Manjaro, etc)? Do you have AppArmor? Then disable that.
@rsramkis commented on GitHub (Oct 6, 2025):
Distro: EndeavourOS
Kernel: 6.16.10-zen1-1-zen
Desktop: GNOME v: 49.0
I disabled Apparmor in the kernel and rebooted and got the following as firefox successfully started:
This is the firefox.local file I used for this test:
@Bundy01 commented on GitHub (Oct 7, 2025):
Hi,
1- I added
whitelist /usr/share/glycin-loadersinwhitelist-usr-share-common.inc.2- Add
noblacklist ${PATH}/bwrap(ArchLinux).3- If
private-binis in the profile, addbwrap.4- If
memory-deny-write-executeis present in the profile, uncomment the line or delete it.Regards.
@kinoegit commented on GitHub (Oct 7, 2025):
I had added all of what you suggested: no success with brave and mullvad-browser but with librewolf (firefox fork)
@Bundy01 commented on GitHub (Oct 7, 2025):
@kinoegit I just installed Firefox to test it and I don't need to make any additions, it works natively. I'm posting the local files.
firefox.profile
firefox-common.profile
@rsramkis commented on GitHub (Oct 7, 2025):
1- I added
whitelist /usr/share/glycin-loadersinwhitelist-usr-share-common.inc.2- Add
noblacklist ${PATH}/bwrap(ArchLinux).3- If
private-binis in the profile, addbwrap.4- If
memory-deny-write-executeis present in the profile, uncomment the line or delete it.memory-deny-write-executeconfiguration is not set in firefox.local, firefox.profile and firefox-common.profile.With the new settings I get the following output launching firefox from terminal:
Firefox version information:
So still not working with the recommended firefox.local settings.
@Bundy01 commented on GitHub (Oct 7, 2025):
@rsramkis I don't understand, with the two files I posted, I don't need to authorize bwrap, so there are no related errors.
You need to install both files in
~/.config/firejail.What distribution are you using?
For seccomp, I only have
seccomp !chroot.If it still doesn't work, you'll have to comment out the lines in both files. Once Firefox launches, uncomment them in small batches until you find the offending line(s).
@rsramkis commented on GitHub (Oct 7, 2025):
Distro: EndeavourOS
Kernel: 6.16.10-zen1-1-zen
Desktop: GNOME v: 49.0
I totally missed the step of replacing the firefox.profile and firefox-common.profile files with your versions. My versions of these files are the latest from the Arch Repositories. I have now replaced my firefox.profile and firefox-common.profile and firefox is still crashing on start.
Question, when you mentioned "For seccomp, I only have seccomp !chroot", were you referring to the firefox.local file?
@Bundy01 commented on GitHub (Oct 7, 2025):
Yes, on the file provided.
If you still get an error mentioning bwrap when you try to launch Firefox, add what I put above (1, 2, and 3) in my posted files.
If it still doesn't work, you'll have to comment out the lines one by one to find the culprit.
@rsramkis commented on GitHub (Oct 7, 2025):
I went ahead and started commenting out lines for firefox.profile and firefox-common.profile. Anything I commented out has '##'.
This is the configuration which lets me run firefox where the whitelist-usr-share-common.inc file is back to its default settings. Note that I had to comment out lines in the firefox.local configuration file too.
firefox.profile
firefox-common.profile
firefox.local:
Here are the results of starting firefox from terminal:
@Bundy01 commented on GitHub (Oct 7, 2025):
@rsramkis You commented out the line
include firefox-common.profile, so your firefox-common.profile file is being ignored.I recommend working directly on my files in
~/.config/firejail/firefox.profileand~/.config/firejail/firefox-common.profile(that's what it's for)When you find the problematic lines, uncomment them one by one to make sure they are all problematic.
Please post the result to help other users.
@rsramkis commented on GitHub (Oct 7, 2025):
Correction. I just un-commented the firefox-common.profile. This is the results with firefox running successfully with the above stated configuration:
firefox run
Since the results are proving that the profile files being read from /etc/firejail, I don't feel there is a need to move them to my home directory. Additionally I did temporarily replace my profile file with your copies of firefox.profile and firefox-common.profile which showed that firefox was still crashing. I did use MELD to compare your files to make sure I could check for where no changes were made.
Before I started the uncommenting testing I reversed out all changes to get myself back to a vanilla setup (with the Arch Repository files).
One other thing I noticed as I was re-testing now:
When I ran firefox again I got:
firefox run
Rebooted and confirmed the results. My guess is that since apparmor is not loaded because I commented it out in the firefox-common.profile. This is why we get the below output and firefox runs. Just no competing sandbox.
@Bundy01 commented on GitHub (Oct 7, 2025):
Copying the profiles from /etc/firejail to ~/.config/firejail allows you to keep your changes. Otherwise, they will be overwritten by a Firejail update (local files take priority over /etc).
If I understand your changes correctly, you commented out the lines
whitelist /usr/share/*,whitelist ${RUNUSER}/*, andapparmor. + firefox.local file.Perhaps there is a file that Firefox needs in /usr/share that is not listed in
whitelist-usr-share-common.inc.However, I checked this file locally and only added the line
whitelist /usr/share/glycin-loaders. I don't understand why it works for me and didn't work for you (same version of Firefox and Firejail).Last question: Can you confirm that all these lines are necessary to launch Firefox?
@rsramkis commented on GitHub (Oct 8, 2025):
Due to the complexity of my configuration files I will re-share them below at the working state (as I see come mistakes in your summary above e.g. firefox.local is not commented out):
firefox.local:
firefox.profile
firefox-common.profile
whitelist-usr-share-common.inc
@ilikenwf commented on GitHub (Oct 8, 2025):
Well this breaks lots of things for me...librewolf/firefox save dialog, signal save dialog, transmission-remote dialog...
There a workaround yet? On arch there is this maybe https://aur.archlinux.org/packages/gdk-pixbuf2-noglycin
edit: the package above fixes it
@ilikenwf commented on GitHub (Oct 8, 2025):
I attempted that potential fix specific to my system, to librewolf, but for one the file paths vary by distro in 1-2 cases and it didn't actually work here.
@rsramkis commented on GitHub (Oct 8, 2025):
Hi Bundy,
I was thinking about the issue and I wanted to compare notes on the setup you are testing on:
Can you provide the Distro, Desktop and Kernel version.
Can you run the two commands from your terminal:
a.
sudo aa-enabledto verify apparmor is enabled.b.
sudo aa-statusto get your apparmor status.Mine:
apparmor commands
Mine is in the kernel string via grub
Source: https://wiki.archlinux.org/title/AppArmor
Thanks
@Bundy01 commented on GitHub (Oct 8, 2025):
Archlinux with Cinnamon and linux 6.17.1.arch1-1 (during testing was 6.16.10.arch1-1)
sudo aa-enabled yes
sudo aa-status
Yes, enabled with systemd-boot
whitelist-usr-share-common.inc
@derfehler commented on GitHub (Oct 10, 2025):
Here are the commands that will help fix the icons if you are using gdk-pixbuf2-noglycin:
@BlueMax commented on GitHub (Oct 10, 2025):
Thanks. 'noglycin' is not necessary anymore though. It works properly with the default packages now (as stated in the follow-up posts).
@derfehler commented on GitHub (Oct 11, 2025):
Does it actually work with default packages? Without this:
?
Without this, nothing works with gdk-pixbuf2 2.44.3-1 from the official Arch Linux repository. Issues persist with other programs like GIMP and Chromium. I don't like this !chroot,!mount,!pivot_root,!umount2 — I really don't, kinda don't like ignore apparmor. I don't understand the point of glycin if we already isolate everything using firejail?
@BlueMax commented on GitHub (Oct 12, 2025):
It still needs the relaxations, yes.
@SkewedZeppelin commented on GitHub (Oct 16, 2025):
2.0.1 should fix this: https://gitlab.gnome.org/GNOME/glycin/-/merge_requests/295
but I just tested fedora 43 with 2.0.3 and it still occurs
@SkewedZeppelin commented on GitHub (Oct 24, 2025):
I'd like to see this fixed soon, either in Firejail or directly in Glycin if possible.
I'm starting a bounty at USD$100 worth of XMR (Monero).
Currently valid until 2025-12-01.
Here is some related reading:
cc @valoq
@valoq commented on GitHub (Oct 25, 2025):
There is a fallback in glycin that works just fine if bwrap is not available https://github.com/roddhjav/apparmor.d/issues/903
If you block access to /usr/bin/bwrap to prevent its execution, glycin will run without its internal sandbox. At the moment it seems to be used only by gdk-pixbuf to load icons, which does not call for sandboxing anyway since it renders only the application supplied icons as I understand it. That said, other applications may eventually use glycin to render images from untrusted sources and since they can confine a small subprocess, it will be a more effective sandbox then what firejail does for the entire application that uses glycin. In other words this workaround needs to be watched closely to only block bwrap for applications that require it for only gdk-pixbuf but not for applications that use glycin for external image rendering because the later will weaken the overall security.
@SkewedZeppelin commented on GitHub (Oct 25, 2025):
I noted above that it doesn't seem to work. Firejail already default blocks bwrap in disable-common.inc yet, many profiles fail to even launch.
@valoq commented on GitHub (Oct 26, 2025):
The other permissions required by glycin still need to be allowed for the fallback.
There are two kinds of crashes caused by blocking permissions for glycin/gdk-pixbuf:
If you allow all the permissions in the linked profile in your firejail configuration, it should run without crashes with the fallback option.
Update:
This is how the solution looks like in apparmor https://github.com/roddhjav/apparmor.d/pull/918/files
@lucasmz-dev commented on GitHub (Oct 26, 2025):
seems like this is happening in F43 KDE as well
@t-m-w commented on GitHub (Nov 5, 2025):
I'm not sure of the merits vs the workaround above, but an alternative crash-prevention workaround for Mozilla applications that worked for me in Fedora 43 with KDE Plasma was to add this to
firefox-common.local:...and then set
widget.use-xdg-desktop-portal.file-pickerto1for Firefox/Librewolf (viaabout:config) and for Thunderbird (via Config Editor button, found by searching Settings for "config").This apparently forces the native file picker to be used (KDE's in my case), vs the default of
2which decides for you.These changes were mentioned in this comment / elsewhere in that issue: https://github.com/netblue30/firejail/issues/6927#issue-3485455591
edit: Downsides are mentioned in the above link, too; you may end up trying to save somewhere that the browser has no permissions to save, which will fail.
@Toquita3D commented on GitHub (Nov 20, 2025):
Non-techy user here, but is this why I lost my minimize/maximize/close buttons on Firefox? (Fedora 43 KDE)
@lucasmz-dev commented on GitHub (Nov 20, 2025):
Yeah same here. I had to stop using firejail for now. It seems to also cause performance issues while moving the window, fullscreen and the issue isn't there. https://github.com/netblue30/firejail/issues/6946
@NetSysFire commented on GitHub (Nov 20, 2025):
If you happen to use Arch Linux, you may want to try https://aur.archlinux.org/packages/gdk-pixbuf2-noglycin until stuff starts getting fixed. I have switched to it myself because so many things have broken everywhere.
@carlsampurna commented on GitHub (Nov 20, 2025):
I've installed gdk-pixbuf2-noglycin in /usr/local/lib and put this:
env LD_LIBRARY_PATH=/usr/local/lib
in e.g. ~/.config/firejail/firefox.local
@Semuria commented on GitHub (Nov 22, 2025):
Since updating Fedora on 43, Firefox Thunderbird and even pdf-viewer is only possible in -noprofile config.
I tend to deactivate it till fix is there
@Dieterbe commented on GitHub (Nov 27, 2025):
thanks @NetSysFire - that seems to make things work again ! @carlsampurna i didn't need to do those customizations you mention, merely installing the package (which will replace the stock gdk-pixbuf2) does the job for me (on Arch, btw)
@carlsampurna commented on GitHub (Nov 27, 2025):
yes, that's easier than what I suggested, I just didn't want to lose the sandboxing in gdk-pixbuf2 except when running under firejail. I used this patch to the -noglycin PKGBUILD so it would install without replacing:
gdk-pixbuf2-noglycin-patch.txt
@monxa commented on GitHub (Nov 27, 2025):
Additionally to
https://aur.archlinux.org/packages/gdk-pixbuf2-noglycin
you might want install
https://aur.archlinux.org/packages/librsvg-noglycin
for various icons (e.g. gimp and inkscape) as suggested by shoryuken.
Uses rust package with 2024 manifest, might have to run
rustup update.@martinetd commented on GitHub (Nov 29, 2025):
For fedora 43 I also had to allow /usr/libexec/glycin-loaders:
I also considered providing a dumbed-down bwrap inside the jail (something that won't do anything and just run the given program), but:
So, I guess our best bet would be to get glycin to skip bwrap if running with bwrap failed -- I've opened https://gitlab.gnome.org/GNOME/glycin/-/issues/244 to see how they feel about it since I didn't see anyone else asking (sorry if it's a dup...)
@qjerome commented on GitHub (Dec 8, 2025):
@martinetd
I investigated a bit around the issue you've posted on gnome (as I am having the same issue as everyone here).
Where you ask why
28005a815edoesn't fix the issue.The answer I found is simply because we end up in that branch of the code:
Unfortunately the error returned by bwrap called from inside
firejailaren't in that allow list.If
/proc/sys/kernel/overflowuidisn't accessible,bwraperrors out:If
/proc/sys/kernel/overflowuidis available but seccomp isn't aligned with what bwrap expects, we get:None of these are in the allow list to detect if glycin is already running in a sandbox.
By extension, if you replace the
bwrapbinary with the following everything works (assuming the profile changes below):Profile changes:
I think the proper fix would be to actually try to identify in a reliable way if glycin inherits some sandboxing context (like seccomp filters by checking
/proc/self/status) rather than relying on some hardcoded magic strings.Finally, I found a simple way to test if
glycinis working:gtk-demobinaryExample:
@qjerome commented on GitHub (Dec 8, 2025):
OK, so here is a simple yet hacky solution that solves the issue (you'll need to change stuffs back when a proper patch lands in glycin). This solution prevents from being relaxed on the seccomp policy of several programs but also from installing some packages from AUR (which might not be acceptable for some users).
sudo mv /usr/bin/bwrap /usr/bin/bwrap.orig/usr/bin/bwrapwith the following inside:sudo chmod +x /usr/bin/bwrap~/.config/firejail/globals.local):firejail --profile=/etc/firejail/firefox.profile gtk-demo-> Click on "Pixbufs": if you get a moving image you won the fightWhen an acceptable fix has landed for
glycin, just run:@paranoid-porygon commented on GitHub (Dec 14, 2025):
I tried this on Arch but it unfortunately did not work for me. Had to resort to installing the gdk-pixbuf2-noglycin and librsvg-noglycin packages from the AUR, which did work.
@netblue30 commented on GitHub (Dec 19, 2025):
I have a simple fix in git:
I've replaced bwrap inside the sandbox with a "do-nothing" program, so our new bwrap just runs the target without any sandboxing. The replacement is visible only inside the sandbox, bwrap is left untouched in the real filesystem.
This will solve a number of other problems reported so far, like this one: https://github.com/netblue30/firejail/issues/6913. Everywhere you see the newer gdk-pixbuf and/or glycin, a regular seccomp/namespaces sandbox at application level will fail. It will also impact existing AppArmor and SELinux profiles.
I also did a test on Fedora latest. They managed to blow up most gtk applications, anything from simple apps like galculator, all the way up to inkscape and firefox.
I am pushing for a firejail release in January, it will be a lot of fun!
@rusty-snake commented on GitHub (Dec 19, 2025):
I don't think this is a good idea (in the long run). The most app-internal sandboxes provide better isolation than firejail.
@netblue30 commented on GitHub (Dec 19, 2025):
Sure, no problem. I'll add a command and disable bwrap replacement and let the user play it one way or the other from the profile file. But it needs to be a bwrap based on user namespaces not on SUID.
@netblue30 commented on GitHub (Dec 26, 2025):
All set for now, Fedora looks fine. On Arch I've found only gimp and inkscape misbehaving.
To re-enable bwrap use --allow-bwrap.
I'll keep the issue open until the new release in January, thanks @myrslint.
@Gerenuk commented on GitHub (Dec 28, 2025):
I'm not sure where to ask, but I'm using Firefox and had the same problem with the file dialog. The AI told me to use the Plasma file dialog instead with:
and it works. I actually like the Plasma file dialog better.
But can someone let me know if this is OK security-wise?
@netblue30 commented on GitHub (Jan 4, 2026):
@Gerenuk
I don't think there are any security issues with it. I would add it at the end of firefox-common.profile commented out, maybe some other users will find it helpful and integrate it locally in their firefox profile.
https://github.com/netblue30/firejail/blob/master/etc/profile-a-l/firefox-common.profile
@netblue30 commented on GitHub (Jan 4, 2026):
Closed for now.
@fjthrowaway commented on GitHub (Jan 6, 2026):
the workaround in 0.9.78 works well but it does add a few seconds delay before the program (firefox in this case) starts, or is it just me?
it starts quick with --allow-bwrap
@netblue30 commented on GitHub (Jan 7, 2026):
No delay here (Debian stable). I've seen the problem so far on Fedora, and on a small number of programs in Arch. I don't think Arch updates all applications when a library changes, but who knows... By Summer it will be all over the place.
@NetSysFire commented on GitHub (Jan 8, 2026):
Arch Linux only updates, more accurately, rebuilds packages when a dependency of them gets updated. I think the package maintainers use rebuilderd for this but unsure. Arch Linux in general does not statically compile things and soname bumps would break a great deal if not all of the relevant applications are updated (a so called partial upgrade).
Whatever the cause of the performance issues, it will indeed likely propagate.
@spaceman7777 commented on GitHub (Jan 22, 2026):
Hmm. So, this change to default firejail to replace bwrap with a dummy/non-functional fbwrap application, committed as part of #7009 , has me a bit worried.
Recently, Claude Code, and quite a few other AI Agent tools, have taken to carefully blocking the agent's capabilities in an extremely fine-grained way using bubblewrap.
It has also become a very common development pattern in recent months to let coding agents skip all user permissions checks, and run continuously for many hours (or even days) at a time.
I'm particularly concerned about folks who are using "Firejail by Default". Because, with this new behavior, if they happen to invoke one of these AI Agents from a firejailed application, these security checks will now suddenly be completely bypassed.
I'm sure there are quite a few people out there that were already using both firejail and Claude Code on their systems, and are executing AI Agents from a wide variety of applications that they have configured with a firejail config.
But, unless they've read this thread, and the patches over on #7009 , they won't know that their coding agents are now running in a radically different sandbox configuration.
Anyway: I would highly recommend not disabling bubblewrap by default via fbwrap, and instead finding a way to disable it on an as-needed basis.
The potential blast radius for a suddenly un-sandboxed AI Agent can be very large.
@netblue30 @kmk3
@spaceman7777 commented on GitHub (Jan 22, 2026):
An example to illustrate why changing the default behavior to replace bwrap with a fake version is a dangerous change:
So, the default profile for Jetbrains IDEs, like Intellij/idea.sh, allows full access to ssh, ~/.ssh , the internet, and large parts of the $HOME directory.
Jetbrains IDEs (and VSCode, and its many variants) currently launch Claude Code as a subprocess, from the IDE.
CC and others do some basic checking for commands that aren't allowed by the currently configured policy, but several rely on Bubblewrap to back this up, and to truly prevent bad things from happening. (Via subprocesses of allowed commands, and a variety of other sneaky things that various AI Models have been known to try.)
Some worst case scenarios involve: Claude Code can now access the system's ~/.ssh directory, and any API keys/secrets stored in projects in $HOME, and send them to an external server.
Even worse, with this change, Claude Code can now actually edit its own configuration files at ~/.claude , which is a whole extra can of worms.
Anyway, I hope that makes my concern a bit more clear.
@Dieterbe commented on GitHub (Jan 23, 2026):
thanks for raising this @spaceman7777 . It seems you're saying that with the (committed) code change, running applications via firejail can be actually worsen security than running applications without firejail. That seems definitely like a problem to address.
unfortunately it seems this was released in 0.9.78, 2 days ago https://github.com/netblue30/firejail/releases/tag/0.9.78
I have emailed @netblue30 as per instructions in https://github.com/netblue30/firejail/blob/master/SECURITY.md
@rusty-snake commented on GitHub (Jan 23, 2026):
Warned you: https://github.com/netblue30/firejail/issues/6906#issuecomment-3675685591
@rusty-snake commented on GitHub (Jan 23, 2026):
One could also ask glycin/claude guys to detect tampering with bwrap executable and reject.
@netblue30 commented on GitHub (Jan 27, 2026):
@spaceman7777:
That's quite easy to fix, just blacklist ~/.ssh and you are done. Send a pull request and we will merge it in. Somehow the author of that specific profile considered ~/.ssh as being necessary (is he is running git directly from the graphical interface?), or he just made a mistake.
Maybe we should make a rule here: if a program already uses a sandbox we should not attempt to build a profile for it. There are so many unsandboxed apps out there, about 20000 in Debian alone, we shouldn't waste our time with applications that are already sandboxed. As an example, we don't touch snap and flatpak apps, instead we go for appimage because nobody builds sandboxes for them.
No intention to sandbox them here - closed source code. As I said, 20000 open-source apps in Debian alone. With 1000 handled by Firejail, we are just scratching the surface.
Something you should look for when dealing with programs using bwrap:
I've seen very few people using a seccomp-bpf filter in bwrap, probably because they don't have one. You can grab our default seccomp filter for 64bit architecture from /usr/lib/firejail/seccomp. Just pass it to bwrap and you should be fine.
@SkewedZeppelin commented on GitHub (Jan 27, 2026):
I authored it in 2017 and allowed it because most people use git from within the IDE and expect that to work.
I personally just use the CLI. And these days I don't even run any IDE on my host, but each within its own dedicated VM without access to keys/secrets/ssh, which is something I recommend everyone to do.
edit: iirc advanced users were/are always expected to make their own overrides if they want stricter profiles
@netblue30 commented on GitHub (Jan 27, 2026):
That's what I thought! I used myself for a long time svn+ssh directly from emacs. Somehow in these development editors people go directly to the code repository (git, svn, whatever), do merges, and whatnot. The dedicated VM is a good idea!
One more example: ssh over http/https:
Some cloud providers give the developer a web page looking like a bash terminal, where they invite the developer to ssh into the server. I've seen it first on Digital Ocean, no idea how is implemented. It is a convenience feature, and requires the presence of ~/.ssh directory inside the browser.
@spaceman7777 commented on GitHub (Jan 29, 2026):
I was only using the descriptions of potential functionality above as examples of why introducing this new behavior to peoples' existing, already-vetted, setups might be a bad move, on the whole, i.e., the stuff that bubblewrap is being widely used to sandbox and secure isn't trivial in scale, and quietly disabling it on people's systems will almost certainly bite many (some, quite severely).
Anyway. My suggestion is that It would be better to just have fbwrap fail, unless an option is specifically set to "bypass bwrap", (in addition to the new flag which allows actual bwrap to run).
Just, some sort of extra logic in fbwrap, to ensure it isn't just running any old program, without the intended sandboxing, would be great. Because, as it stands, this new functionality introduces a rather broad security vulnerability.
(Consider the case where some other program quietly introduced new logic that replaced
firejailinvocations with afake-firejailthat runs all of the previously-firejail-sandboxed applications, and subprocesses of firejailed applications, without any of firejail's security restrictions. I think many around here would find functionality of that sort quite concerning. That's the perspective I wanted to draw attention to.)If I were to guess, fixing this issue now, when it is still primarily affecting a small number of applications, will likely prevent a much larger headache down the line.
@netblue30 commented on GitHub (Jan 30, 2026):
This is very very bad, don't do it! Firejail is SUID! The moment you call firejail from inside your program, any decent security monitoring tool will detect the rise in privileges and kill your program.
The same goes for user namespace. Userns is currently interpreted as a rise in privileges by both firejail and apparmor. And so does bwrap. Like a bunch of attack dogs chasing the same rabbit, they always end up killing each other.
And here you have a firejail user running Tor browser - actual glycin/bwrap bug reported earlier: https://github.com/netblue30/firejail/issues/6913. Everything worked fine yesterday, until he updated his system. And now Tor goes down in flames because gnome pixbuf cannot securely paint windows decorations. The irony in this is absolutely ridiculous!
Actually, most users posting here also have apparmor running. Apparmor is much faster than firejail, I'm starting to think it was apparmor crashing the program. Anyway, the problem affected about 200 profiles in firejail. It also affected any user running apparmor without firejail. This is a github link to a large collection of apparmor profiles and the problem report: https://github.com/roddhjav/apparmor.d/issues/881
@spaceman7777 commented on GitHub (Jan 31, 2026):
Yeah, I was just making the comparison. Like, if you updated the minor version of a program on your system, and found out later that it had started silently replacing firejail invocations with fake-firejail invocations, it would be a bit upsetting.
That's the situation many users have been put into by this too-broad change to bubblewrap behavior.