Allow creating identifiable bus broker connections for containers

[WhyNotHugo]

Following up on this long thread: https://fosstodon.org/@zeenix@toot.cat/111002189225139704

The original proposal is here: https://bugs.freedesktop.org/show_bug.cgi?id=100344

And there's an ongoing discussion on the dbus issue tracker: https://gitlab.freedesktop.org/dbus/dbus/-/issues/171

This is required to eventually fix this issue: flatpak/xdg-desktop-portal#737

TLDR

Some dbus applications (e.g.: xdg-desktop-portal) receive requests from other peers and need to know whether that peers is in a sandbox. In case that they are in a sandbox, they need to know a bit more information about it (specifically: sandbox_engine, app_id and instance_id).

The following method would be used to pass a new fd to the broker. The broker would listen to new connections on this socket, and all client connections made through it would be tagged as belonging to the specified sandbox.

o.fd.DBus.Containers.AddContainerServer(
    s: container_type,           # e.g. "org.flatpak"
    s: app_identifier,           # e.g. "org.gnome.Recipes"
    a{sv}: metadata,             # defined by Flatpak in this case
    h: socket_to_accept,         # see link
    h: ready_notification,       # see link
    h: close_notification,       # see link
    a(usos): rules,              # see link, #Access control
) -> s: container_id

Some notes:

• metadata should not be included here; any metadata that the sandbox engine needs it should store on its own memory.
• I would add an instance_id field here (and below). This would also align with the Wayland protocol which has the exact same purpose.
• rules is probably out of scope; see my notes on ACL below.

Aside from the above, other clients can use the following method to check whether they're receiving a message from a sandboxed peer:

o.fd.DBus.GetConnectionCredentials(s: bus_name) -> a{sv}
    {
        ... all the current fields ...,
        "ContainerID": <"47">,
        "ContainerType": <"org.flatpak">,
        "ContainerApp": <"org.gnome.Recipes">,
    }

The original link issue (from 2017) also proposes including ACL in this scope. I'm not sure if this is still desirable, since this can be handled out-of-process in an xdg-dbus-proxy instance.

[zeenix]

Thanks @WhyNotHugo for writing this. Should this be on busd instead. zbus will of course need to provide bindings but that's trivial.

[WhyNotHugo]

Oh, true. Can you move the issue for me (I think as the owner you have permissions, right?).

[zeenix]

Oh, true. Can you move the issue for me (I think as the owner you have permissions, right?).

done.

[swick]

Others seem to agree that the metadata map is useful and we should standardize the keys as a separate xdg spec so we can share them with the wayland-security context protocol.

[WhyNotHugo]

Others seem to agree that the metadata map is useful and we should standardize the keys as a separate xdg spec so we can share them with the wayland-security context protocol.

The wayland-security context has these fields as metadata:

• sandbox_engine
• app_id
• instance_id

I agree that using those same fields is what makes sense the most.

[swick]

We're talking about metadata that's not the identity such as the desktop file name.