Introduce XDP_APP_INFO_KIND_CONTAINERS1 which gets all information from D-Bus #1268

swick · 2024-01-18T19:50:59Z

Get the org.fdo.DBus.Containers1 idea rolling!

flatpak: flatpak/flatpak#5656
dbus: https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/449

This falls back to the PID based lookup (flatpak/snap) if D-Bus doesn't support the new interface.

Remaining issues, everything else is supposed to work:

Remapping paths (xdp_app_info_remap_path, xdp_app_info_get_path_for_fd) is not supported
Dynamic Launcher's TryExec (xdp_app_info_get_tryexec_path) is not supported

Should be ready for review.

swick · 2024-01-23T16:54:54Z

Found a few bugs and CI is green.

GeorgesStavracas

Thanks for working on this. Just a pair of comments so far, but I don't think I'm the best person to review this. It would have helped if the commits had commit messages.

data/org.freedesktop.portal.Device.xml

src/xdp-utils.c

A shell of its former self remains which informs any potential user about the removal. The Device portal is, to the best of our knowledge, not used by any component. It's also weird because it's not a portal expoed to clients which caused confusion. The service it provides is also provided by the permission store, minus the ability to map from arbitrary PID to an app id. This PID to app id mapping isn't something that can be done in general and is most likely broken when the PID is not of the xdg-dbus-proxy.

One was a left-over and for the other we just removed the last users.

This will become useful once we support the dbus Containers1 interface and a new XDP_APP_INFO kind can still refer to a flatpak.

…fo_sync This will make it easier to follow which method of identiying an app will be used under what conditions.

swick · 2024-01-23T18:26:43Z

Made the commit messages much more useful and addressed the review.

Who is the person I should nag for a review then?

smcv · 2024-01-23T18:51:24Z

Who is the person I should nag for a review then?

Please be patient, I will get to this when I can. Nagging potential reviewers is likely to be counterproductive.

GeorgesStavracas · 2024-01-23T19:01:17Z

@swick thanks. I was going to mention @smcv , but since they're already aware of this PR, let's wait for their review.

smcv

(I haven't reviewed everything in detail)

src/xdp-utils.c

smcv · 2024-02-02T13:17:55Z

src/xdp-utils.c

+  if (app_info->kind == XDP_APP_INFO_KIND_FLATPAK)
+    return xdp_app_info_ensure_pidns_flatpak (app_info, proc, error);
+
+  if (app_info->kind == XDP_APP_INFO_KIND_HOST)
+    return xdp_app_info_ensure_pidns_host (app_info, proc, error);
+
+  if (app_info->kind == XDP_APP_INFO_KIND_CONTAINERS1)
+    return xdp_app_info_ensure_pidns_containers1 (app_info, proc, error);


I think this deserves to be a switch().

data/org.freedesktop.portal.Device.xml

src/device.c

src/xdp-utils.c

smcv · 2024-02-02T13:32:12Z

src/xdp-utils.c

+  if (g_variant_lookup (metadata, "DesktopFile", "&s", &desktop_file))
+    app_info->u.containers1.desktop_file = g_strdup (desktop_file);


As I mentioned on flatpak/flatpak#5656, this isn't a standardized field. I know this because we haven't yet defined any standardized fields, or even where you would go to standardize them!

Instead of returning either NULL with error, NULL without error and non-NULL without error, adhere to GLib convention and return either TRUE with an out param set or FALSE with an error set.

The org.fdo.DBus.GetConnectionCredentials method gives us both a PID (ProcessID) and a pidfd (ProcessFD) in one roundtrip. It fails when the PID can't be retrieved but allows the pidfd to be -1. The pidfd will become useful for host and Containers1 clients later.

Returns a GVariant containign all the metadata that a container engine like flatpak has set on the socket for this app instance. This contains the container type, app id, instance id and additional arbitrary metadata such as the desktop file name. If the D-Bus broker doesn't support the Containers1 interface or the app using the portal is not running in a container, we fall back to the other ways of identifying apps. This specifically means it's safe to run a D-Bus broker which supports Containers1 while flatpak doesn't. Eventually we want to remove the flatpak and snap specific paths at which point it's a requirement to have a Containers1 capable flatpak.

Both host apps and Containers1 apps can do pid mappings via pidfd. This is some prep work for that.

Do some best effort pid remapping for host apps. This will only work when the D-Bus broker supports pidfd (ProcessFD).

This new app kind is authenticated by D-Bus and x-d-p gets all the information about the app from D-Bus which itself get the information from the sandbox engine which set up the sandbox of the app. Currently only flatpak and dbus (dbus-daemon) supports this mechanism but it can be supported by any other sandbox engine, such as snap and firejail. This also means that an app with XDP_APP_INFO_KIND_CONTAINERS1 can still be a flatpak or a snap app. The goal is to make as many paths in x-d-p agnostic to the actual sandbox engine and handle all XDP_APP_INFO_KIND_CONTAINERS1 apps the same. Eventually we can then remove any other XDP_APP_INFO_KIND variants. This commit sets up a XdpAppInfo object with all the metadata x-d-p will need. The follow up commit implements various XdpAppInfo functionalities.

Uses some of the metadata from Containers1 directly and falls back to the flatpak path in some cases. Some of the fallbacks can be removed once the D-Bus broker supports ACL and we can get rid of xdg-dbus-proxy. The path remapping and tryexec functionalities are not implemented right now.

swick · 2024-02-08T22:28:51Z

Tried to pull out the non-Containers1 bits to #1281.

GeorgesStavracas · 2024-04-04T19:03:35Z

This can be rebased now

swick · 2024-05-24T20:24:48Z

Turns out a few things can't really be expressed with just some key value pairs, such as path remapping and the details of installing dynamic launchers. I'm going to use the metadata to pass a bus and object which implements a common Contaienrs1 interface. Flatpak then implements this interface in the flatpak-session-helper and x-d-p can offload the functionality there.

swick force-pushed the wip/containers1 branch from 7b0cc56 to 69067cb Compare January 23, 2024 16:06

swick changed the title ~~Wip/containers1~~ Introduce XDP_APP_INFO_KIND_CONTAINERS1 which gets all information from D-Bus Jan 23, 2024

swick marked this pull request as ready for review January 23, 2024 16:08

swick force-pushed the wip/containers1 branch 5 times, most recently from 68dff4e to 2d9f7a9 Compare January 23, 2024 16:50

GeorgesStavracas reviewed Jan 23, 2024

View reviewed changes

data/org.freedesktop.portal.Device.xml Outdated Show resolved Hide resolved

src/xdp-utils.c Outdated Show resolved Hide resolved

swick added 6 commits January 23, 2024 19:25

utils: Make unused functions private

b18b893

One was a left-over and for the other we just removed the last users.

utils: Add xdp_app_info_is_flatpak

bd33109

This will become useful once we support the dbus Containers1 interface and a new XDP_APP_INFO kind can still refer to a flatpak.

utils: Move PID lookup into its own function

b9ad755

utils: Refactor xdp_get_app_info_from_pid

fa954ce

utils: Move xdp_get_app_info_from_pid to xdp_connection_lookup_app_in…

0793641

…fo_sync This will make it easier to follow which method of identiying an app will be used under what conditions.

swick force-pushed the wip/containers1 branch from 2d9f7a9 to f659c5a Compare January 23, 2024 18:25

smcv requested changes Feb 2, 2024

View reviewed changes

swick force-pushed the wip/containers1 branch 2 times, most recently from 6c366f8 to 03d9394 Compare February 8, 2024 20:13

utils: Get rid of tri-state app info creation

6bb06d7

Instead of returning either NULL with error, NULL without error and non-NULL without error, adhere to GLib convention and return either TRUE with an out param set or FALSE with an error set.

swick force-pushed the wip/containers1 branch from 03d9394 to 3e5a617 Compare February 8, 2024 20:38

swick added 5 commits February 8, 2024 22:21

utils: Remove unused xdp_connection_get_pid

df88e79

utils: Move AppInfo cache insertion into its own function

1537fd5

utils: Make pid mappings via pidns more generic

7315913

Both host apps and Containers1 apps can do pid mappings via pidfd. This is some prep work for that.

swick added 3 commits February 8, 2024 22:22

utils: Support pid/tid mapping for host apps

ca85d7e

Do some best effort pid remapping for host apps. This will only work when the D-Bus broker supports pidfd (ProcessFD).

swick force-pushed the wip/containers1 branch from 3e5a617 to b342409 Compare February 8, 2024 21:22

swick mentioned this pull request Feb 8, 2024

AppInfo cleanups, pidfd based pid mapping, device portal removal #1281

Merged

swick marked this pull request as draft June 3, 2024 17:04

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introduce XDP_APP_INFO_KIND_CONTAINERS1 which gets all information from D-Bus #1268

Introduce XDP_APP_INFO_KIND_CONTAINERS1 which gets all information from D-Bus #1268

swick commented Jan 18, 2024 •

edited

swick commented Jan 23, 2024

GeorgesStavracas left a comment

swick commented Jan 23, 2024

smcv commented Jan 23, 2024

GeorgesStavracas commented Jan 23, 2024

smcv left a comment

smcv Feb 2, 2024

smcv Feb 2, 2024

swick commented Feb 8, 2024

GeorgesStavracas commented Apr 4, 2024

swick commented May 24, 2024

		if (g_variant_lookup (metadata, "DesktopFile", "&s", &desktop_file))
		app_info->u.containers1.desktop_file = g_strdup (desktop_file);

Introduce XDP_APP_INFO_KIND_CONTAINERS1 which gets all information from D-Bus #1268

Are you sure you want to change the base?

Introduce XDP_APP_INFO_KIND_CONTAINERS1 which gets all information from D-Bus #1268

Conversation

swick commented Jan 18, 2024 • edited

swick commented Jan 23, 2024

GeorgesStavracas left a comment

Choose a reason for hiding this comment

swick commented Jan 23, 2024

smcv commented Jan 23, 2024

GeorgesStavracas commented Jan 23, 2024

smcv left a comment

Choose a reason for hiding this comment

smcv Feb 2, 2024

Choose a reason for hiding this comment

smcv Feb 2, 2024

Choose a reason for hiding this comment

swick commented Feb 8, 2024

GeorgesStavracas commented Apr 4, 2024

swick commented May 24, 2024

swick commented Jan 18, 2024 •

edited