[Bug]: Flatpak app inside Docker fails with: Could not connect: No such file or directory

[jonathon-love]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug that matches the one I want to file, without success.
• If this is an issue with a particular app, I have tried filing it in the appropriate issue tracker for the app (e.g. under https://github.com/flathub/) and determined that it is an issue with Flatpak itself.
• This issue is not a report of a security vulnerability (see here if you need to report a security issue).

Flatpak version

1.12.7

What Linux distribution are you using?

Ubuntu

Linux distribution version

22.04

What architecture are you using?

x86_64

How to reproduce

running the flatpak app org.jamovi.jamovi inside a docker container (either at build, or runtime) produces the error: Could not connect: No such file or directory. i am the maintainer of org.jamovi.jamovi, and don't think the error is related to jamovi itself. the jamovi executable is defined here and i don't think it is ever called.

any idea what might be going on here?

Expected Behavior

jamovi will start

Actual Behavior

Could not connect: No such file or directory

Additional Information

is it perhaps related to the finish args? (tbh, i'm not sure which of these are necessary).

        "--share=network",
        "--share=ipc",
        "--socket=x11",
        "--socket=pulseaudio",
        "--device=dri",
        "--filesystem=home",
        "--env=TMPDIR=/var/tmp",
        "--talk-name=org.freedesktop.Notifications"

oh, i should add, jamovi is an electron application, which i appreciate won't run properly in a docker container (:P), however it has some command line tools which i'm trying to use here ...

[smcv]

running the flatpak app org.jamovi.jamovi inside a docker container

Running one container technology (like Flatpak) inside another container technology (like Docker) is generally problematic.

Please describe exactly what you are doing, in terms of the precise Docker and Flatpak commands to get from a normal shell environment to the failing Flatpak command?

It would probably be useful to try to reproduce this with a very simple, known-good Flatpak command like:

flatpak install flathub org.freedesktop.Platform//21.08
flatpak run --command=bash org.freedesktop.Platform//21.08

The successful result is that you get a shell in the container with a distinctive prompt like [📦 org.freedesktop.Platform ~]$ and the failing result is some error.

If that works, please start adding --share=network, etc. until you find a minimal failing command.

When you have reached a minimal failing command, please try running it as flatpak run -v -v ... to get more information.

[smcv]

Also please try to put a title on issue reports so that there's some context.

[jonathon-love]

hi,

thanks, this is really high quality advice/help.

this is my minimal docker file which reproduces the error (note that no --share needs to be added):

FROM ubuntu:22.04 as base

RUN DEBIAN_FRONTEND=noninteractive apt update && apt install -y --no-install-recommends \
    flatpak ca-certificates

RUN flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
RUN flatpak install --user -y flathub org.freedesktop.Platform//21.08
RUN flatpak run -v -v --command=bash org.freedesktop.Platform//21.08

#8 0.315 F: No installations directory in /etc/flatpak/installations.d. Skipping
#8 0.331 F: Opening system flatpak installation at path /var/lib/flatpak
#8 0.333 F: Opening user flatpak installation at path /root/.local/share/flatpak
#8 0.335 F: Opening user flatpak installation at path /root/.local/share/flatpak
#8 0.336 F: Opening system flatpak installation at path /var/lib/flatpak
#8 0.341 F: Opening user flatpak installation at path /root/.local/share/flatpak
#8 0.362 error: Could not connect: No such file or directory

Also please try to put a title on issue reports so that there's some context.

sorry! my attention was captured by the big form to fill in, and i didn't notice the title at the top!

with thanks

[Murmele]

I have the same issue with flatpak 1.14.0.

The reason having it into a docker is, because in my case it runs in a CI to check the appdata file:
flatpak run --env=G_DEBUG=fatal-criticals org.freedesktop.appstream-glib validate UDPLogger.appdata.xml

[dbrgn]

Same thing here, I want to validate a metainfo XML in CI.

Steps to reproduce:

$ docker run --rm -ti --privileged node:16.15-bullseye /bin/bash
# apt-get update && apt-get install -y flatpak
# flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
# flatpak install -y --noninteractive org.freedesktop.appstream-glib
# flatpak run org.freedesktop.appstream-glib validate

This will result in:

error: Could not connect: No such file or directory

Maybe the problem is that the dbus daemon is not started inside the Docker container (since it doesn't use an init system)? If yes, how could dbus be started in a way that flatpak is happy?

[Murmele]

@dbrgn I found a workaround for it:

I used directly the appstream-util tool

apt install --yes appstream-util
G_DEBUG=fatal-criticals appstream-util validate-relax

[bcooksley]

For the record, this has also impacted the KDE project which builds a custom Docker image to assist with providing a Flatpak CI on our side.

While installing many of the dependent Flatpak components we need works fine, io.qt.qtwebengine.BaseApp for some reason needs to connect to D-Bus as part of the installation process, which leads to us hitting this error.

It would be nice if the Flatpak devs could eliminate calls out to the System Bus when the application in question isn't even being run - or at the very least make it clear why it is failing and not require the utilisation of strace to debug the issue.

[refi64]

FWIW we work around this in our CI via:

dbus-send --system /org/freedesktop/DBus org.freedesktop.DBus || dbus-daemon --system --fork

(I did not write this, but it's a pretty short-and-sweet workaround.)

IIRC this is due to the parental controls checks?

[travier]

Reading

flatpak/common/flatpak-dir.c

Line 8460 in be2de97

if (on_session != NULL)

I set FLATPAK_SYSTEM_HELPER_ON_SESSION=foo in our Dockerfile and got a build passing: https://invent.kde.org/sysadmin/ci-images/-/merge_requests/99.

This looks like a parental check bypass but not sure.

[smcv]

The parental controls stuff via libmalcontent is explicitly not a security boundary, either in Flatpak or in libmalcontent more generally: if a child who is subject to parental controls can run arbitrary code (as in arbitrary Unix shell commands), then it shouldn't come as a surprise to find that they can run arbitrary code (as in Flatpak apps they weren't meant to). After all, a sufficiently technically-proficient child with access to a command-line could compile their own copy of flatpak(1) with that check patched out.

Perhaps a reasonable strategy would be to do some g_file_test() before trying to connect to the system bus for this (or alternatively, after the attempt to connect to it fails), and "fail open" if neither /run/dbus/system_bus_socket nor /var/run/dbus/system_bus_socket exists? That seems like it would do the right thing for your Docker use-case? (Merge requests very welcome if you happen to get to this before anyone else does.)

[smcv]

See also #2797 and #3902 among other issues with discussion of the extent to which this is (not) a security boundary.

[nanonyme]

The test makes sense. We were also wary of enabling libmalcontent at all in freedesktop-sdk build of flatpak due to fear of complications.

[dbnicholson]

Perhaps a reasonable strategy would be to do some g_file_test() before trying to connect to the system bus for this (or alternatively, after the attempt to connect to it fails), and "fail open" if neither /run/dbus/system_bus_socket nor /var/run/dbus/system_bus_socket exists? That seems like it would do the right thing for your Docker use-case? (Merge requests very welcome if you happen to get to this before anyone else does.)

I mentioned this over here, but I think it might make sense to fail open all the time since you can just set DBUS_SYSTEM_BUS_ADDRESS to any legitimate address and you can bypass the check since neither malcontent nor accounts-service will be available. So, the security boundary already isn't there.

However, I think if you wanted the more restrictive check like above, you could:

1. Check if you got G_IO_ERROR_NOT_FOUND
2. Get the address with g_dbus_address_get_for_bus_sync
3. Return TRUE if it's unix:path=/var/run/dbus/system_bus_socket or unix:path=/run/dbus/system_bus_socket.

[dbnicholson]

I marked #5609 as fixing this issue, but that only affects running apps. If that approach is deemed acceptable, I can change the install path to do that too (basically in place of the FLATPAK_SYSTEM_HELPER_ON_SESSION environment variable).

[dbnicholson]

Sorry, as mentioned above, I think this should be reopened since I only handled the run process and not the install process that kicked this all off. Now that you merged my simple change, I'm happy to adapt it to be done during install, too.