common: Use org.fdo.DBus.Containers1 to create the session bus #5656
Conversation
|
I think CI will be fixed with a simple rebase, now that d5f891e landed |
swick
force-pushed
the
wip/dbus-containers1
branch
from
02a984d
to
671a441
Compare
There was a problem hiding this comment.
#890 is an earlier attempt at this. It isn't directly reusable (the API proposed in dbus has changed since then) but it would be useful to look at it and see if anything from there would be an improvement here.
In #890, I was doing the actual D-Bus calls in the dbus-proxy (which, at the time, was integrated into Flatpak rather than being a separate component), but I could well believe that it's better to do it in flatpak itself.
In #890, there's a comment with a diagram of how the overall system fits together, and I think salvaging that would be a very good thing to have.
| g_variant_builder_add (&b, "{sv}", "DesktopFile", | ||
| g_variant_new_string (desktop_file)); | ||
| g_variant_builder_add (&b, "{sv}", "NetworkAccess", | ||
| g_variant_new_boolean (network_access)); |
There was a problem hiding this comment.
These are not standardized fields. I know this because we haven't yet defined any standardized fields, or even where you would go to standardize them!
It's fine to use non-standardized fields in a private prototype, but we shouldn't seriously consider merging them, so I think having somewhere that we can standardize them is a blocker for this.
We could consider using org.flatpak.DesktopFile, org.flatpak.NetworkAccess and assuming that, whatever mechanism we have for standardization, it will do the obvious thing with reversed domain names - but I think that's probably not what you want, because I think you probably want NetworkAccess to be something that e.g. Snap apps can also set.
In the absence of any formal spec for these fields, I'll comment on them briefly here.
NetworkAccess presumably wants to be a tristate (true, false, not-present-in-dict), where true means "network namespace shared with host, no isolation", false means "no network access", and not-present-in-dict means "unable to say either way" or "it's complicated".
For DesktopFile I'm not sure what it's for, and I'm not sure that hard-coding %s.desktop is really correct. I thought that a Flatpak app like (say) com.valvesoftware.Steam can export multiple entry points if it wants to, like for example Steam might plausibly have both com.valvesoftware.Steam.desktop and com.valvesoftware.Steam.RemotePlayClient.desktop?
In #890, I was assuming that the metadata would be fully container-engine-defined, so instead of attempting to standardize anything, I created an ad-hoc serialization of the same things that are in /.flatpak-info. We probably don't want that any more, though.
In #890, I integrated creation of this metadata dict into flatpak_context_save_metadata(), which I think could be worth considering - it's a subset of the same information in a different format.
There was a problem hiding this comment.
(https://gitlab.freedesktop.org/dbus/dbus/-/issues/479 is the issue for standardizing what appears in the metadata dict.)
There was a problem hiding this comment.
For
DesktopFileI'm not sure what it's for, and I'm not sure that hard-coding%s.desktopis really correct. I thought that a Flatpak app like (say)com.valvesoftware.Steamcan export multiple entry points if it wants to, like for example Steam might plausibly have bothcom.valvesoftware.Steam.desktopandcom.valvesoftware.Steam.RemotePlayClient.desktop?
A real-world example is that Flatpak app cat.xtec.clic.JClic on Flathub provides both cat.xtec.clic.JClic.jclic.desktop and cat.xtec.clic.JClic.jclicauthor.desktop (and, notably, does not seem to provide cat.xtec.clic.JClic.desktop as assumed here).
There was a problem hiding this comment.
I wouldn't want to merge anything before we get snap on board either way.
I added the metadata to figure out what kind of things are probably required to get good support in x-d-p but we could easily drop that before merging and use the flatpak app info kind in x-d-p by default.
swick
force-pushed
the
wip/dbus-containers1
branch
2 times, most recently
from
5e61739
to
9638f5e
Compare
swick
force-pushed
the
wip/dbus-containers1
branch
from
9638f5e
to
a5bebaa
Compare
|
Added some explanation and ascii art showing the session bus setup. |
dbus will hopefully enable the org.freedesktop.DBus.Containers1 interface in the next release. This does the authentication part but no ACL, so the xdg-dbus-proxy still has to remain for now. I will also implement support in xdg-desktop-portals which then uses the interface instead of poking in /proc/$pid/root.
dbus MR for enabling the interface: https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/449
/cc @smcv @alexlarsson