I had weird errors when working on a godot project:
addons/godot-sqlite/bin/libgdsqlite.linux.template_debug.x86_64.so: failed to map segment from shared object.
ERROR: Can't open GDExtension dynamic library: 'res://addons/godot-sqlite/gdsqlite.gdextension'.
These addons are executable files. Addons like these are common enough
and `noexec` breaks them. I confirmed that the change fixes this error
and allows loading addons.
To make hardware tokens available for ordinary users, some distributions
include a udev rule to make the corresponding entry in /dev available
for users belonging to a specific group.
In the case of Void Linux, it now uses the `plugdev` group for FIDO2
access[1] and when using a YubiKey, it appears as the following device
nodes:
$ find /dev -group plugdev | LC_ALL=C sort -u
/dev/hidraw1
/dev/hidraw2
$ ls -l /dev/hidraw1 /dev/hidraw2
crw-rw---- 1 root plugdev 240, 1 Mar 7 19:53 /dev/hidraw1
crw-rw---- 1 root plugdev 240, 2 Mar 7 19:53 /dev/hidraw2
[1] https://github.com/void-linux/void-packages/pull/54519
To avoid CI failures.
From the first run of `cppcheck_old` on commit 8f69e9841 ("bugfix:
firecfg: check full filename in check_profile() (#6674)", 2025-03-04)
[1]:
> This is a scheduled Ubuntu 20.04 brownout. Ubuntu 20.04 LTS runner
> will be removed on 2025-04-01. For more details, see
> https://github.com/actions/runner-images/issues/11101
The target depends on the cppcheck version from Ubuntu 20.04 in order to
work properly and this distribution will become EOL next month (April
2025), so just remove the target.
Added on commit 53f0b3950 ("CI: keep old cppcheck job and ignore two
files in new job that take too long to check", 2022-07-26).
[1] https://github.com/netblue30/firejail/actions/runs/13658953453/job/38185280665
Changes:
* Block access to /dev/ntsync by default
* Add the `keep-dev-ntsync` command to allow access to /dev/ntsync (even
if `private-dev` is used)
* Add `keep-dev-ntsync` to wine.profile and similar profiles
Closes#6655.
Apparently the .desktop file for `seahorse` is located in the following
path:
* `/usr/share/applications/org.gnome.seahorse.Application.desktop`
Which ends in `Application.desktop` instead of `seahorse.desktop`,
leading to it not being automatically detected by firecfg.
So add a redirect profile and an entry in firecfg.config.
Related commits:
* bd9761508 ("Temp fix firecfg (#2634)", 2019-04-02)
* 8f69e9841 ("bugfix: firecfg: check full filename in check_profile()
(#6674)", 2025-03-04).
Fixes#6658.
Relates to #2624.
Reported-by: @ginto37
Reported-by: @rusty-snake
Currently, firecfg only checks the last word in .desktop files when
trying to match them to an existing profile. For example:
* `org.gnome.gedit.desktop` -> `gedit.desktop`
* `org.gnome.seahorse.Application.desktop` -> `Application.desktop`
This works in the former case where there is an exact match of the last
word on each side (`gedit.desktop` and `gedit.profile`), but not in the
latter case (`Application.desktop` and `seahorse.profile`).
So make firecfg also check the full filename of the .desktop file, to
make it easier to create redirect profiles that match the full name of
the .desktop files. For example:
* `org.gnome.seahorse.Application.desktop` ->
`org.gnome.seahorse.Application.profile` (which itself then redirects
to `seahorse.profile`)
Related commits:
* a6341b904 ("disable DBus activation in firecfg", 2017-09-25)
* 3e69deba3 ("fix firecfg", 2017-09-25)
* bd9761508 ("Temp fix firecfg (#2634)", 2019-04-02)
Relates to #2624#6658.
Remmina may install this wrapper binary on some distributions.
On Void Linux, this is the default binary launched via application
launchers (e.g. rofi):
$ grep "Exec" /usr/share/applications/org.remmina.Remmina.desktop
TryExec=remmina-file-wrapper
Exec=remmina-file-wrapper %U
[...]
Apparently the main binary has been renamed from `ytmdesktop` to
`youtube-music-desktop-app`[1]:
$ pacman -Qlq ytmdesktop
[...]
/opt/ytmdesktop/youtube-music-desktop-app
/usr/bin/youtube-music-desktop-app
/usr/share/applications/ytmdesktop.desktop
So add a redirect for it.
Fixes#6662.
[1] https://github.com/netblue30/firejail/issues/6662#issuecomment-2681532969
Reported-by: @Dieterbe
Fix a failing assert when running `firejail` inside:
`firejail --chroot=somedir --noprofile`
firejail: ../../src/firejail/util.c:1039: create_empty_dir_as_root:
Assertion `(s.st_mode & 07777) == (mode)' failed.
The assert is checking whether the newly created `/run/firejail/dbus`
empty directory, has the correct mode set, which in this case is `0755`.
The issue is that, since the directory already exists and has the mode
`0400`, because of the first ran chroot command, the assert fails.
This commit circumvents this issue, by making `firejail` ignore the dbug
directory entirely, in the `src/firejail/preproc.c` file when compiling
the project using `configure --disable-dbusproxy`.
There's also really no need for `firejail` to care about that directory
if `--disable-dbusproxy` is used.
