Bubblewrap everywhere

Flapper · 2025-09-23 14:08:32

Just updated today, everything seems to start within bwrap.
OK, Firefox I can understand, but mousepad, solitaire (sol)?

Is there a way to disable bubblewrap?

jim002 · 2025-09-23 15:08:41

yes, there are multiple instances of glycin and bwrap on xfce 4.20
go there:
(https://bbs.archlinux.org/viewtopic.php?id=308448)
https://bbs.archlinux.org/viewtopic.php?id=302145&p=2

correctmost · 2025-09-23 19:16:20

gdk-pixbuf 2.44 uses glycin for loading images and glycin uses bubblewrap for sandboxing.

Many of the bwrap processes are hanging around because of a timeout issue that will be fixed in the next version of glycin: https://gitlab.gnome.org/GNOME/glycin/- … quests/302

karabaja4 · 2025-09-24 01:54:53

I really dislike the idea of a library starting processes to do stuff, especially if it's not going to cleanup after itself - like sudden hanging bwrap processes in my ps ax.

Is there a way to have latest gdk-pixbuf2 but not use glycin/bwrap (e.g. what would happen if I compile latest gdk-pixbuf2 without glycin support - would it still work)?

EDIT: Seems to work with this patch applied.

Last edited by karabaja4 (2025-09-24 02:04:45)

undriven · 2025-09-24 05:43:49

karabaja4 wrote:

I really dislike the idea of a library starting processes to do stuff, especially if it's not going to cleanup after itself - like sudden hanging bwrap processes in my ps ax.

Strongly agree. gdk-pixbuf2 is used by too many programs for this kind of scope creep to be acceptable.

mpan · 2025-09-24 06:09:29

The situation can be resolved by temporarily downgrading gdk-pixbuf2 to 2.42.12-2, until a proper fix is deployed. At least up to 2.44.2-1, both are so-name compatible.

The cleanup issue is bug and is going to be fixed. So that can’t be used as an argument for or against anything.

As for the processes: this is a typical “out of sight, out of mind” situation. If glycin used threads instead of processes, nobody would complain, because the former are not displayed by default in process managers. Yet any relatively modern GUI program runs 5–100 of them. The only “problem” is that, since glycin can’t achieve with threads the separation required, it has to spawn processes. Which makes them visible.

Last edited by mpan (2025-09-24 06:12:26)

kinghol · 2025-09-24 07:25:22

but I like that the Linux Desktop is trying to become a bit more secure.

Flapper · 2025-09-24 09:02:37

There were no bubblewrap processes for me, because it was not installed until yesterday.
It doesn't appear to have a config file or anything, so is there a way to remove it or prevent it sandboxing everything?

karabaja4 · 2025-09-24 09:58:29

mpan wrote:

The cleanup issue is bug and is going to be fixed. So that can’t be used as an argument for or against anything.
As for the processes: this is a typical “out of sight, out of mind” situation. If glycin used threads instead of processes, nobody would complain, because the former are not displayed by default in process managers. Yet any relatively modern GUI program runs 5–100 of them. The only “problem” is that, since glycin can’t achieve with threads the separation required, it has to spawn processes. Which makes them visible.

I would argue that this kind of a bug is the argument. If a process ides, all the threads die with it, it's self contained. Threads are an internal mechanic of a process and user has no control over it.

Processes however are seen and controlled by the user. If a process spawns bunch of other processes, someone has the responsibility of cleaning that up, and as I understand it, this will not even be the responsibility of a parent process, instead a timeout will be implemented so the child processes just die after a certain period (https://gitlab.gnome.org/GNOME/glycin/- … quests/302). And for a library to do this, it feels like losing control over what processes my computer is running and hoping it just all works out - but I guess that's a common thing these days...

Last edited by karabaja4 (2025-09-24 10:08:01)

undriven · 2025-09-24 10:15:08

mpan wrote:

As for the processes: this is a typical “out of sight, out of mind” situation. If glycin used threads instead of processes, nobody would complain, because the former are not displayed by default in process managers. Yet any relatively modern GUI program runs 5–100 of them. The only “problem” is that, since glycin can’t achieve with threads the separation required, it has to spawn processes. Which makes them visible.

It's a bad design from the start. The implementation should have been a separate user daemon instead of slapped into the library. It already does work over dbus, surely having the library keep the process tree clean and talk to a sandboxed daemon isn't a big ask. Instead every program that uses pixbuf2 now spams instances of bwrap just to read an image file. Insane.

tekstryder · Today 13:44:51

correctmost wrote:

gdk-pixbuf 2.44 uses glycin for loading images and glycin uses bubblewrap for sandboxing.
Many of the bwrap processes are hanging around because of a timeout issue that will be fixed in the next version of glycin: https://gitlab.gnome.org/GNOME/glycin/- … quests/302

glycin 2.0.0-5 has pulled in a slew of recent upstream commits and bubblewrap is no longer everywhere haha.

bwrap processes are exiting as expected.

@Flapper: Please test the latest package and mark as SOLVED if you can no longer reproduce the issue.

silikone · Today 15:58:03

We were warned about this a while ago.
https://blogs.gnome.org/sophieh/2025/06 … ing-safer/

It's a simple compilation option, so one can easily circumvent the problem by using a custom PKGBUILD. I find it unfortunate that upstream took the liberty of making it the default, though. Safety is one of my last concerns on something like Arch.

seth · Today 19:54:19

gLyCiN PrOvIdEs mAnY SeCuRiTy bEnEfItS OvEr eXiStInG SoLuTiOnS DuE To tHe uSe oF ThE RuSt pRoGrAmMiNg

My punching ball is gonna have a tough night…

mpan · Today 22:42:35

If I understand the situation correctly: the language choice doesn’t relate to the issues at hand and, in particular, they aren’t caused by the use of Rust.

Arch Linux

#1 2025-09-23 14:08:32

Bubblewrap everywhere

#2 2025-09-23 15:08:41

Re: Bubblewrap everywhere

#3 2025-09-23 19:16:20

Re: Bubblewrap everywhere

#4 2025-09-24 01:54:53

Re: Bubblewrap everywhere

#5 2025-09-24 05:43:49

Re: Bubblewrap everywhere

#6 2025-09-24 06:09:29

Re: Bubblewrap everywhere

#7 2025-09-24 07:25:22

Re: Bubblewrap everywhere

#8 2025-09-24 09:02:37

Re: Bubblewrap everywhere

#9 2025-09-24 09:58:29

Re: Bubblewrap everywhere

#10 2025-09-24 10:15:08

Re: Bubblewrap everywhere

#11 Today 13:44:51

Re: Bubblewrap everywhere

#12 Today 15:58:03

Re: Bubblewrap everywhere

#13 Today 19:54:19

Re: Bubblewrap everywhere

#14 Today 22:42:35

Re: Bubblewrap everywhere

Board footer