[GH-ISSUE #1736] transmission-qt freezes on opening dialogs

gitea-mirror commented

2026-05-05 07:35:38 -06:00

Owner

Originally created by @hubiqs on GitHub (Jan 16, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1736

When trying to open dialogs in transmission-qt, the interface freezes and the application becomes a zombie. This includes using buttons Open, Open URL, and any dialog from the menues. The application must then be terminated manually.

This happens using the default profiles with no changes or .local-files. Running transmission-qt without firejail works fine. This behaviour has been confirmed on two separate systems running Arch, using basically the same config.

I believe this problem came about when KDE Frameworks was upgraded to 5.41.0, but I'm not certain. Might have happened on Qt upgrade to 5.10.0. Downgrading to test is troublesome for me running Arch, I'd rather not mess up my install, as I'm not an expert user. On that note, I'm not sure how to generate any meaningful logs. Nothing appears in the terminal, nor anything in the syslog that I can see.

This is all I get when it freezes and then manually TERMd:

$ transmission-qt
Reading profile /etc/firejail/transmission-qt.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/whitelist-common.inc
Reading profile /etc/firejail/whitelist-var-common.inc
Parent pid 3343, child pid 3344
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted
Blacklist violations are logged to syslog
Child process initialized in 59.02 ms

Child received signal 15, shutting down the sandbox...

Parent is shutting down, bye...

If there's any more information I can supply, let me know, it's been quite a while now since I could use transmission-qt in firejail normally. For now I've been starting it outside firejail, adding the URLs I need, closing it, and then doing the downloads inside firejail (while making sure not to open any dialogs.)

firejail 0.9.52-1
transmission-qt 2.92-8
KDE Plasma 5.11.5
KDE Frameworks 5.42.0
Qt 5.10.0
Kernel 4.14.13-1 with CONFIG_USER_NS=y

Edit: Adding that $ firejail --noprofile /usr/bin/transmission-qt works fine, so the problem is the profile?

Edit 2: Sometimes when I click a button, it spits out an error in the console as it freezes:
UdevQt: unable to create udev monitor connection

Originally created by @hubiqs on GitHub (Jan 16, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/1736 When trying to open dialogs in transmission-qt, the interface freezes and the application becomes a zombie. This includes using buttons Open, Open URL, and any dialog from the menues. The application must then be terminated manually. This happens using the default profiles with no changes or .local-files. Running transmission-qt without firejail works fine. This behaviour has been confirmed on two separate systems running Arch, using basically the same config. I believe this problem came about when KDE Frameworks was upgraded to 5.41.0, but I'm not certain. Might have happened on Qt upgrade to 5.10.0. Downgrading to test is troublesome for me running Arch, I'd rather not mess up my install, as I'm not an expert user. On that note, I'm not sure how to generate any meaningful logs. Nothing appears in the terminal, nor anything in the syslog that I can see. This is all I get when it freezes and then manually TERMd: ``` $ transmission-qt Reading profile /etc/firejail/transmission-qt.profile Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-devel.inc Reading profile /etc/firejail/disable-passwdmgr.inc Reading profile /etc/firejail/disable-programs.inc Reading profile /etc/firejail/whitelist-common.inc Reading profile /etc/firejail/whitelist-var-common.inc Parent pid 3343, child pid 3344 Warning: /sbin directory link was not blacklisted Warning: /usr/sbin directory link was not blacklisted Blacklist violations are logged to syslog Child process initialized in 59.02 ms Child received signal 15, shutting down the sandbox... Parent is shutting down, bye... ``` If there's any more information I can supply, let me know, it's been quite a while now since I could use transmission-qt in firejail normally. For now I've been starting it outside firejail, adding the URLs I need, closing it, and then doing the downloads inside firejail (while making sure not to open any dialogs.) firejail 0.9.52-1 transmission-qt 2.92-8 KDE Plasma 5.11.5 KDE Frameworks 5.42.0 Qt 5.10.0 Kernel 4.14.13-1 with CONFIG_USER_NS=y --- Edit: Adding that ```$ firejail --noprofile /usr/bin/transmission-qt ``` works fine, so the problem is the profile? --- Edit 2: Sometimes when I click a button, it spits out an error in the console as it freezes: ```UdevQt: unable to create udev monitor connection```

gitea-mirror closed this issue

2026-05-05 07:35:39 -06:00

gitea-mirror commented

2026-05-05 07:35:41 -06:00

Author

Owner

@hubiqs commented on GitHub (Jan 16, 2018):

Commenting out memory-deny-write-execute in transmission-qt.profile seems to solve the problem. Any ideas what could be wrong?

@hubiqs commented on GitHub (Jan 16, 2018): Commenting out ```memory-deny-write-execute``` in transmission-qt.profile seems to solve the problem. Any ideas what could be wrong?

gitea-mirror commented

2026-05-05 07:35:42 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jan 17, 2018):

Might be the QT bug again. Try the thing here.

@chiraag-nataraj commented on GitHub (Jan 17, 2018): Might be the QT bug again. Try the thing [here](https://github.com/netblue30/firejail/issues/1709#issuecomment-355862576).

gitea-mirror commented

2026-05-05 07:35:44 -06:00

Author

Owner

@hubiqs commented on GitHub (Jan 17, 2018):

Oh I should have mentioned that I've tried that, I need env QML_DISABLE_DISK_CACHE=1 in order to fix okular anyway. Might still be related perhaps? The okular problems showed up at the same time as the transmission-qt ones.

@hubiqs commented on GitHub (Jan 17, 2018): Oh I should have mentioned that I've tried that, I need ```env QML_DISABLE_DISK_CACHE=1``` in order to fix okular anyway. Might still be related perhaps? The okular problems showed up at the same time as the transmission-qt ones.

gitea-mirror commented

2026-05-05 07:35:47 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jan 17, 2018):

Hmmm, that's weird. memory-deny-write-execute breaking it implies that transmission is doing some truly weird stuff imo...maybe use a different torrent client? 😜
[Edit] memory-deny-write-execute seems to break darktable as well, which is a favorite program of mine...I guess I'll have to revise my statement above 😜

@chiraag-nataraj commented on GitHub (Jan 17, 2018): Hmmm, that's weird. `memory-deny-write-execute` breaking it implies that `transmission` is doing some truly weird stuff imo...maybe use a different torrent client? :stuck_out_tongue_winking_eye: [Edit] `memory-deny-write-execute` seems to break `darktable` as well, which is a favorite program of mine...I guess I'll have to revise my statement above :stuck_out_tongue_winking_eye:

gitea-mirror commented

2026-05-05 07:35:48 -06:00

Author

Owner

@hubiqs commented on GitHub (Jan 17, 2018):

Haha, maybe. But, it seems memory-deny-write-execute was added in August to transmission-qt.profile which means it has been like that since September's firejail 0.9.50 at least, and I definitely haven't had the problem that long, and transmission-qt was not updated during this time. Since okular and transmission-qt started misbehaving at the same time, I would still suspect Qt...

@hubiqs commented on GitHub (Jan 17, 2018): Haha, maybe. But, it seems ```memory-deny-write-execute``` was added in August to ```transmission-qt.profile``` which means it has been like that since September's firejail 0.9.50 at least, and I definitely haven't had the problem that long, and transmission-qt was not updated during this time. Since okular and transmission-qt started misbehaving at the same time, I would still suspect Qt...

gitea-mirror commented

2026-05-05 07:35:50 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 18, 2018):

Doing QML_DISABLE_DISK_CACHE=1 and QTWEBENGINE_DISABLE_SANDBOX=1 by default (hardcoded).

commit: 1e7045b55c

@hubiqs - grab the latest from git and give it a try. Try also darktable. Do we still need to remove memory-deny-write-execute? Thanks.

@netblue30 commented on GitHub (Jan 18, 2018): Doing QML_DISABLE_DISK_CACHE=1 and QTWEBENGINE_DISABLE_SANDBOX=1 by default (hardcoded). commit: https://github.com/netblue30/firejail/commit/1e7045b55cc1e189dba6d9ed21c05c90663f3736 @hubiqs - grab the latest from git and give it a try. Try also darktable. Do we still need to remove memory-deny-write-execute? Thanks.

gitea-mirror commented

2026-05-05 07:35:50 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jan 18, 2018):

@netblue30 I think you misunderstood. I added memory-deny-write-execute in my local darktable profile just to see if it worked. It's not in the default profile.

@chiraag-nataraj commented on GitHub (Jan 18, 2018): @netblue30 I think you misunderstood. I added `memory-deny-write-execute` in my local `darktable` profile just to see if it worked. It's not in the default profile.

gitea-mirror commented

2026-05-05 07:35:52 -06:00

Author

Owner

@hubiqs commented on GitHub (Jan 18, 2018):

@netblue30 I tried the latest version from master, and the problem with transmission-qt remains. Removing memory-deny-write-execute from transmission-qt.profile is still necessary.
Please note that env QML_DISABLE_DISK_CACHE=1 is still present here:
a28fc4b2cd/etc/disable-common.inc (L347)
I commented it out, and tested okular, the hard-coded fix works fine for okular.

As far as darktable goes, it works fine in 0.9.52 and master. Adding memory-deny-write-execute doesn't break it for me (what specific breakage are you seeing @chiraag-nataraj?) but it is probably best left out at this time, since something's going on... But darktable isn't connected to anything Qt, is it?

@hubiqs commented on GitHub (Jan 18, 2018): @netblue30 I tried the latest version from master, and the problem with transmission-qt remains. Removing ```memory-deny-write-execute``` from transmission-qt.profile is still necessary. Please note that ```env QML_DISABLE_DISK_CACHE=1``` is still present here: https://github.com/netblue30/firejail/blob/a28fc4b2cd3c459ff87664aa4b761242aa1c2dc7/etc/disable-common.inc#L347 I commented it out, and tested okular, the hard-coded fix works fine for okular. As far as darktable goes, it works fine in 0.9.52 and master. Adding ```memory-deny-write-execute``` doesn't break it for me (what specific breakage are you seeing @chiraag-nataraj?) but it is probably best left out at this time, since something's going on... But darktable isn't connected to anything Qt, is it?

gitea-mirror commented

2026-05-05 07:35:53 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jan 18, 2018):

@hubiqs darktable fails to start if I include it. Namely, SECCOMP kills darktable after it attempts to use mprotect. Regardless, that's a separate bug, so let's not pollute this issue with that 🙂

@chiraag-nataraj commented on GitHub (Jan 18, 2018): @hubiqs `darktable` fails to start if I include it. Namely, SECCOMP kills `darktable` after it attempts to use `mprotect`. Regardless, that's a separate bug, so let's not pollute this issue with that :slightly_smiling_face:

gitea-mirror commented

2026-05-05 07:35:54 -06:00

Author

Owner

@vn971 commented on GitHub (Jan 18, 2018):

Are there other Qt applications that explicitly need QML_DISABLE_DISK_CACHE=1 and QTWEBENGINE_DISABLE_SANDBOX=1 for them to work in firejail?
If not, I'd say it makes sense to add the rules to transmission-qt profile specifically, instead of disabling qt webengine sandboxing globally for all apps without warning.

@vn971 commented on GitHub (Jan 18, 2018): Are there other Qt applications that explicitly need `QML_DISABLE_DISK_CACHE=1` and `QTWEBENGINE_DISABLE_SANDBOX=1` for them to work in firejail? If not, I'd say it makes sense to add the rules to transmission-qt profile specifically, instead of disabling qt webengine sandboxing globally for all apps without warning.

gitea-mirror commented

2026-05-05 07:35:55 -06:00

Author

Owner

@hubiqs commented on GitHub (Jan 19, 2018):

@vn971 okular and viber seem to need QML_DISABLE_DISK_CACHE=1. Probably connected to this bug.
I'm not aware of any applications that need QTWEBENGINE_DISABLE_SANDBOX=1 to function. It was suggested in the viber-issue, but never reported to have any effect...? 1e7045b55c might have been a bit premature.

transmission-qt doesn't seem to be affected by these options, only negatively by the presence of memory-deny-write-execute, perhaps due to the above Qt bug.

@hubiqs commented on GitHub (Jan 19, 2018): @vn971 okular and viber seem to need ```QML_DISABLE_DISK_CACHE=1```. Probably connected to [this bug](https://bugreports.qt.io/browse/QTBUG-58508). I'm not aware of any applications that need ```QTWEBENGINE_DISABLE_SANDBOX=1``` to function. It was suggested in the [viber-issue](https://github.com/netblue30/firejail/issues/1709), but never reported to have any effect...? https://github.com/netblue30/firejail/commit/1e7045b55cc1e189dba6d9ed21c05c90663f3736 might have been a bit premature. transmission-qt doesn't seem to be affected by these options, only negatively by the presence of ```memory-deny-write-execute```, perhaps due to the above Qt bug.

gitea-mirror commented

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

Author

Owner

@netblue30 commented on GitHub (Jan 19, 2018):

Removed meomory-deny-execute from transmission-qt profile: 5cf5ec2636

Removed QTWEBENGINE_DISABLE_SANDBOX=1 from the code: 5e0daa3cd6

Adding QTWEBENGINE_DISABLE_SANDBOX=1 to Viber profile: edc49d389e

I moved the discussion from #1709 here on this page.

@netblue30 commented on GitHub (Jan 19, 2018): Removed meomory-deny-execute from transmission-qt profile: https://github.com/netblue30/firejail/commit/5cf5ec263660009e86f70b8c6aca156011f7541a Removed QTWEBENGINE_DISABLE_SANDBOX=1 from the code: https://github.com/netblue30/firejail/commit/5e0daa3cd641e459c313f15d459a336ccd063961 Adding QTWEBENGINE_DISABLE_SANDBOX=1 to Viber profile: https://github.com/netblue30/firejail/commit/edc49d389e7531504aa9d7f2bef7a96080b8ccf0 I moved the discussion from #1709 here on this page.

gitea-mirror commented

2026-05-05 07:35:59 -06:00

Author

Owner

@smitsohu commented on GitHub (Mar 7, 2018):

Temporarily reopened for discussion of Qupzilla profile (also relevant for Falkon probably #1794).

Firejailed Qupzilla is broken on a number of distros because Qt webengine is running at its core (just confirmed on Fedora), and I would like to extend the approach taken in KMail and Qutebrowser profiles to Qupzilla, rather than adding QTWEBENGINE_DISABLE_SANDBOX=1 only to preserve the chroot seccomp filter.

While Firejail is modeled after the Chromium sandbox, it cannot replace it.... for users on a distro like Fedora, the security implications of disabling the built-in sandbox (with its tightly constrained renderer processes) and replacing everything with Firejail are non-trivial.

But also users on distros like Debian, where significant parts of the built-in webengine sandbox are not available because of missing support for unprivileged user namespaces, are not left out in the rain. They still have caps.drop sys_admin,sys_chroot and noroot and indeed don't need the chroot seccomp filter that much, precisely because there are no unprivileged user namespaces.

I'd like to propose to move on, at least for browsers and the like, with dropping the chroot seccomp filter instead of replacing the Qt webengine sandbox altogether. Personally the feeling is rather that firejailing an app should always be a no-brainer, independent of the distribution used.

Do I miss something? Other opinions?

@smitsohu commented on GitHub (Mar 7, 2018): Temporarily reopened for discussion of Qupzilla profile (also relevant for Falkon probably #1794). Firejailed Qupzilla is broken on a number of distros because Qt webengine is running at its core (just confirmed on Fedora), and I would like to extend the approach taken in [KMail](https://github.com/netblue30/firejail/blob/15d9ef1ba68914223fcd4a989c9c6df8b7565a1d/etc/kmail.profile) and [Qutebrowser](https://github.com/netblue30/firejail/blob/ca3964fed3f141e75bf396defaec3dca543ce49f/etc/qutebrowser.profile) profiles to Qupzilla, rather than adding QTWEBENGINE_DISABLE_SANDBOX=1 only to preserve the chroot seccomp filter. While Firejail is modeled after the Chromium sandbox, it cannot replace it.... for users on a distro like Fedora, the security implications of disabling the built-in sandbox (with its tightly constrained renderer processes) and replacing everything with Firejail are non-trivial. But also users on distros like Debian, where significant parts of the built-in webengine sandbox are not available because of missing support for unprivileged user namespaces, are not left out in the rain. They still have `caps.drop sys_admin,sys_chroot` and `noroot` and indeed don't need the chroot seccomp filter that much, precisely because there are no unprivileged user namespaces. I'd like to propose to move on, at least for browsers and the like, with dropping the chroot seccomp filter instead of replacing the Qt webengine sandbox altogether. Personally the feeling is rather that firejailing an app should always be a no-brainer, independent of the distribution used. Do I miss something? Other opinions?

gitea-mirror commented

2026-05-05 07:36:00 -06:00

Author

Owner

@Vincent43 commented on GitHub (Mar 7, 2018):

When user namespaces aren't available chromium uses SUID Sandbox (which has same effect but needs setuid binary), you can check it in chrome://sandbox/ . Does Qt webengine do the same?

@Vincent43 commented on GitHub (Mar 7, 2018): When user namespaces aren't available chromium uses SUID Sandbox (which has same effect but needs setuid binary), you can check it in `chrome://sandbox/` . Does Qt webengine do the same?

gitea-mirror commented

2026-05-05 07:36:02 -06:00

Author

Owner

@smitsohu commented on GitHub (Mar 7, 2018):

No, there is no SUID sandbox in Qt webengine, only seccomp and unprivileged namespaces (and a chroot).

When the distro doesn't support unpriv user ns, there is still seccomp, IIRC.

@smitsohu commented on GitHub (Mar 7, 2018): No, there is no SUID sandbox in Qt webengine, only seccomp and unprivileged namespaces (and a chroot). When the distro doesn't support unpriv user ns, there is still seccomp, IIRC.

gitea-mirror commented

2026-05-05 07:36:03 -06:00

Author

Owner

@vn971 commented on GitHub (Mar 7, 2018):

@Vincent43 also binaries are not SUID if you have --noroot working.

@vn971 commented on GitHub (Mar 7, 2018): @Vincent43 also binaries are not SUID if you have `--noroot` working.

gitea-mirror commented

2026-05-05 07:36:04 -06:00

Author

Owner

@Vincent43 commented on GitHub (Mar 7, 2018):

That's why we don't use noroot in chromium profile 😀

@smitsohu Maybe it's worth to open new issue as this isn't related to transmission?

@Vincent43 commented on GitHub (Mar 7, 2018): That's why we don't use `noroot` in chromium profile 😀 @smitsohu Maybe it's worth to open new issue as this isn't related to transmission?

gitea-mirror commented

2026-05-05 07:36:06 -06:00

Author

Owner

@smitsohu commented on GitHub (Mar 13, 2018):

@Vincent43 you're right, I will change my approach the next time

@smitsohu commented on GitHub (Mar 13, 2018): @Vincent43 you're right, I will change my approach the next time

Rows
Columns

[GH-ISSUE #1736] transmission-qt freezes on opening dialogs #1176