github-starred/firejail

Fork 0

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

[GH-ISSUE #3074] KDE apps causing seccomp violations (name_to_handle_at)? #1927

New issue

Closed

opened 2026-05-05 08:35:41 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

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

Owner

Originally created by @smitsohu on GitHub (Dec 7, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3074

A while back there was a report about Qutebrowser issuing name_to_handle_at syscalls, which broke the app in sandboxes started with the default seccomp filter (#2302).

On one system I have now many KDE apps (e.g. Gwenview, Dolphin, Baloo) that are also broken because of the blacklisted name_to_handle_at syscall, which seems to suggest that something in Qt changed recently.

Can someone confirm this?

The affected system is Debian Buster, kernel from backports (5.3.9-2~bpo10+1 (2019-11-13))
Qt 5.11.3, KDE Frameworks 5.54.0

Originally created by @smitsohu on GitHub (Dec 7, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/3074 A while back there was a report about Qutebrowser issuing `name_to_handle_at` syscalls, which broke the app in sandboxes started with the default seccomp filter (#2302). On one system I have now many KDE apps (e.g. Gwenview, Dolphin, Baloo) that are also broken because of the blacklisted `name_to_handle_at` syscall, which seems to suggest that something in Qt changed recently. Can someone confirm this? The affected system is Debian Buster, kernel from backports (5.3.9-2~bpo10+1 (2019-11-13)) Qt 5.11.3, KDE Frameworks 5.54.0

gitea-mirror closed this issue

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

gitea-mirror commented

2026-05-05 08:35:43 -06:00

Author

Owner

@Vincent43 commented on GitHub (Dec 8, 2019):

I tested with gwenview and it works normal. Except kernel they rest of system spec you listed are pretty ancient so this doesn't look like recent change in qt/kde libs.

My system spec: Arch Linux, linux 5.4.2, Qt 5.13.2, KDE Frameworks 5.64.0.

@Vincent43 commented on GitHub (Dec 8, 2019): I tested with gwenview and it works normal. Except kernel they rest of system spec you listed are pretty ancient so this doesn't look like recent change in qt/kde libs. My system spec: Arch Linux, linux 5.4.2, Qt 5.13.2, KDE Frameworks 5.64.0.

gitea-mirror commented

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

Author

Owner

@smitsohu commented on GitHub (Dec 8, 2019):

Except kernel they rest of system spec you listed are pretty ancient so this doesn't look like recent change in qt/kde libs.

Right! It is a Debian after all.

@smitsohu commented on GitHub (Dec 8, 2019): > Except kernel they rest of system spec you listed are pretty ancient so this doesn't look like recent change in qt/kde libs. Right! It is a Debian after all.

gitea-mirror commented

2026-05-05 08:35:45 -06:00

Author

Owner

@FOSSONLY commented on GitHub (Dec 8, 2019):

I'm using Debian-Testing myself and so far I've noticed that Qt or anything based on Qt is treated with seemingly little priority. KDE is very sensitive about this, and doesn't run smoothly or show strange bugs when Qt isn't up to date. I don't know why this always takes forever until there are updates, or what blocks it. Everything based on GTK behaves radially differently, and enjoys very timely updates.

@FOSSONLY commented on GitHub (Dec 8, 2019): I'm using Debian-Testing myself and so far I've noticed that Qt or anything based on Qt is treated with seemingly little priority. KDE is very sensitive about this, and doesn't run smoothly or show strange bugs when Qt isn't up to date. I don't know why this always takes forever until there are updates, or what blocks it. Everything based on GTK behaves radially differently, and enjoys very timely updates.

gitea-mirror commented

2026-05-05 08:35:46 -06:00

Author

Owner

@smitsohu commented on GitHub (Dec 9, 2019):

Nothing relevant for the release. I caused it myself. These apps wanted access to /run/udev, which I didn't grant them, and as a result they started calling name_to_handle_at.

@smitsohu commented on GitHub (Dec 9, 2019): Nothing relevant for the release. I caused it myself. These apps wanted access to /run/udev, which I didn't grant them, and as a result they started calling `name_to_handle_at`.

gitea-mirror referenced this issue

2026-05-05 09:06:18 -06:00

[GH-ISSUE #3861] firejail --list shows nothing #2429

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

No description provided.

Rows
Columns