I use the official Fedora container images to build a flatpak app. However, I notice that starting in Fedora 36, flatpak run
no longer works. Does anyone else notice this problem? Should I file a bug report? I’m not sure if this qualifies as a Fedora-centric issue or if the bug report should go directly upstream with flatpak. I guess that’s why I’m checking here first.
I tried searching to see if any other similar issues were reported, but, not finding any, I dug into things. This is a minimal example to run inside a container:
dnf install -y flatpak
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak install -y flathub org.freedesktop.Platform//21.08
flatpak run org.freedesktop.Platform
If successful, it changes the prompt to [📦 org.freedesktop.Platform /]#
.
Using podman run --privileged --rm -it quay.io/fedora/fedora:35
, everything works as expected. (The --privileged
option addresses this error during flatpak run
: bwrap: Creating new namespace failed: Operation not permitted
.)
However, for both quay.io/fedora/fedora:36
and quay.io/fedora/fedora:37
, they fail with this error message:
error: Could not connect: No such file or directory
Using strace
I tracked where the error originated to this system call, when it attempts to connect to the dbus system bus:
connect(13, {sa_family=AF_UNIX, sun_path="/var/run/dbus/system_bus_socket"}, 110) = -1 ENOENT (No such file or directory)
Inside the containers, dbus isn’t running, so it makes sense that this would fail. I eventually traced down the call to this line inside check_parental_controls()
. Note that if malcontent
support is enabled at compile-time it hits this line, otherwise check_parental_controls()
is always successful.
So why does flatpak work in Fedora 35 but not in Fedora 36? They both have the same version of flatpak:
$ flatpak --version
Flatpak 1.12.7
However, I found that Fedora builds flatpak
with malcontent
support starting in Fedora 36 but it is not applied to Fedora 35.
I don’t know what is the “right” thing to do here. Should dbus run in a container after all? Flatpak seems to handle the lack of dbus just fine except for this parental control check. Should this parental control case be made more robust so that a missing dbus connection is not a total failure? Or some option added to flatpak run
to override the parental control check?