Skip to content

Draft: Bring back the Containers interface

Simon McVittie requested to merge smcv/dbus:containers into master

I would like to get this into dbus 1.16. Rather than letting the perfect be the enemy of the good, I'm aiming to defer everything more complicated (in particular firewall-style filtering, #185) and get something roughly equivalent to https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/security-context/engines.md?ref_type=heads.

/cc @swick @WhyNotHugo @pwithnall

Closes: #477

  • Revert "Disable the Containers interface"

    This reverts commit 9d60676a.

  • Revert "Revert "spec: Document the initial Containers1 interface""

    This reverts commit f8a2a03c.

  • specification: Document container info as containing the creator

    This was added to the implementation after Containers was removed from the spec.

  • specification: Describe the trust model for container info

  • spec: GetConnectionCredentials doesn't include container context metadata

    In early prototypes we put the Type and Name here, but that leads to some difficult questions about whether they can be trusted, and the answer is unfortunately "it depends".

  • CI: Enable Containers1 in debug builds, explicitly disable in reduced build

    This ensures that both "enabled" and "disabled" are tested, regardless of whether it is enabled by default (currently it is not).

    Create /var/local/run/dbus/containers so that we can run the tests.

  • containers: Rename "container instance" to "container server"

    Flatpak has the concept of an "instance ID" for a running app, which we should expose in Containers1, similar to the analogous Wayland specification security-context-v1[1]. If we use the word "instance" for both the Flatpak (or other container manager) side and the D-Bus side, the resulting API will be really confusing.

    [1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/staging/security-context

  • spec: Reduce repetition in Containers1

    All outputs from GetServerInfo are the same as GetConnectionInfo, so only give a very short summary in GetServerInfo.

  • Containers: Replace "name" with the app ID and instance ID

    This aligns it with the analogous Wayland specification security-context-v1, and in particular allows Flatpak-aware applications to look up the instance's sandboxing parameters and other metadata.

    Helps: #479

  • Containers: Reserve all metadata fields for future standardization

    Now that we have the instance ID, Flatpak-aware apps can look up per-instance metadata in a Flatpak-specific way (by reading the file that Flatpak provides), and similarly any other container framework can provide its own mechanism to get extensible metadata; so the value of providing container-manager-defined metadata is perhaps limited.

    However, it seems valuable to have somewhere to put standardized metadata: for example, we could have a shared specification between Wayland and D-Bus to define a name for keys that could be common to multiple sandbox frameworks. For example, it could include a string that is a freedesktop.org app ID, or a string that is an icon name, or a boolean that is true if networking is permitted.

    This takes #479 off the critical path for getting this feature merged.

    Helps: #479

  • containers: Convert out parameters into an a{sv}

    This allows for potential future mechanisms where the caller, rather than the message bus, is responsible for creating the socket, without needing to have a "null-like" representation for the absence of a path and the absence of an address (in practice the empty string).

    I've left the per-container server object path as a top-level thing rather than moving it into the a{sv}, because I don't see any reason why we would want to crate a per-container server without having a way to talk about it in future API calls.

    Requested-by: Sebastian Wick

  • spawn-unix: Move _dbus_unix_make_pipe() to common code

    I want to use this in a test-case.

    Note that this changes the error code used if pipe() fails (which in practice should not happen) from DBUS_ERROR_SPAWN_FAILED to some reasonable interpretation of errno.

  • containers test: Show the AddServer call and response in the log

  • containers test: Add infrastructure for sending fds to AddServer

  • containers test: Factor out waiting for the unconfined connection to close

    We'll want to do this from more than one place in future.

  • containers: Add named arguments to alter how the server is stopped

    This adds the initial named arguments that we anticipate we will need for Flatpak and Snap: Flatpak will want to hold the server open until the xdg-dbus-proxy exits, while Snap developers want to clean up the per-container servers explicitly and have their existence stored as part of the persistent state of the restartable snapd service.

    Resolves: #186

  • containers test: Exercise StopOnDisconnect and StopOnNotify

    In the STOP_SERVER_VIA_NOTIFY test, the server would stop whenever either the mock container manager disconnects from the bus or the notify fd is closed, whichever comes first. In the STOP_SERVER_VIA_NOTIFY_NOT_MANAGER test, we assert that the server does not stop when the mock container manager disconnects, only when the notify fd is closed.

Edited by Simon McVittie

Merge request reports