In some of the tests involving test_stop_server(), the creator of the
server (the mock container engine) already disconnected from the bus,
so it seems worthwhile to check that its credentials can still be
retrieved via GetServerInfo() even though the connection itself is no
longer there.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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: https://gitlab.freedesktop.org/dbus/dbus/-/issues/186
Signed-off-by: Simon McVittie <smcv@collabora.com>
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.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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
Signed-off-by: Simon McVittie <smcv@collabora.com>
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 dbus/dbus#479 off the critical path for getting this feature
merged.
Helps: https://gitlab.freedesktop.org/dbus/dbus/-/issues/479
Signed-off-by: Simon McVittie <smcv@collabora.com>
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: https://gitlab.freedesktop.org/dbus/dbus/-/issues/479
Signed-off-by: Simon McVittie <smcv@collabora.com>
All outputs from GetServerInfo are the same as GetConnectionInfo, so
only give a very short summary in GetServerInfo.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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
Signed-off-by: Simon McVittie <smcv@collabora.com>
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.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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".
Signed-off-by: Simon McVittie <smcv@collabora.com>
Readers of the message bus specification might be encountering Properties
for the first time, so for the basic properties in the o.fd.DBus
interface, link to the interface definition.
I'm not intending to add similar text for extension interfaces like
Containers.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously, we arbitrarily divided o.fd.DBus into "messages"
(methods and signals), in one sect2, and Properties, in another sect2;
and for the only extended interface that is documented so far,
o.fd.DBus.Monitoring, we included its single method in the list of
o.fd.DBus methods.
This is putting too much weight on implementation details of how the
D-Bus protocol is implemented (with Properties being "less core" than
methods and signals), and not enough weight on how interfaces are
conceptually structured. It's more usual to group together all aspects
of an interface into one document or section, and the current arbitrary
separation is going to look more and more odd as we start documenting
more interfaces like Containers (dbus!449), Stats and Verbose.
Instead, repurpose the "Message Bus Messages" section to become the
documentation for the o.fd.DBus interface, and introduce a separate
section for each other interface that the message bus provides.
Each one contains a full list of methods, signals and properties (if any)
if it is specific to the message bus, or a cross-reference to a more
generic interface description if it is equally applicable to the message
bus and its clients.
Prompted by discussion on dbus!449.
Signed-off-by: Simon McVittie <smcv@collabora.com>
doc/index.html.in is common to the Meson and CMake build systems, so
every time a new variable gets substituted into it, both the Meson and
CMake build systems need to provide a value for that variable.
Fixes: b58ca0e1 "cmake: Inclusion of a link in html overview file corrected"
Signed-off-by: Simon McVittie <smcv@collabora.com>
This ensures that the Doxygen-built documentation has the same layout
in the installed files that it does in the build tree and on the
website. If we don't keep the same layout, then there is no value for
the `DBUS_APIDOC_LINK` in index.html that would be correct for both
the build tree and the installed tree. The build tree effectively has
a html subdirectory hard-coded, because that's how Doxygen lays out
its outputs.
This commit is the Meson equivalent of
commit 522633b4 "cmake: install api docs in html subdir" in the CMake
build system (dbus!473, dbus#519).
Signed-off-by: Simon McVittie <smcv@collabora.com>
The newest release of the reference message bus that did not support
GetConnectionCredentials was 1.6.30, almost a decade ago.
It's entirely reasonable for new code to assume that
GetConnectionCredentials will succeed, and not implement a fallback.
Signed-off-by: Simon McVittie <smcv@collabora.com>
`<xref>` will typically be replaced by something like
"the section called “Foo”", so if we want to name a specific method
in running text, we need to use `<link>`.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The `AppArmor` feature flag is a case-sensitive string literal,
so consistently use its correct case-combination.
Signed-off-by: Simon McVittie <smcv@collabora.com>
There's no need to make readers go looking for these in a larger section,
we can link directly to the individual interfaces.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Debian 11 recently reached EOL, and we should really be using the
latest stable release as our reference.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This choice of exe_wrapper doesn't appear to work on Debian 12, causing
a build failure while checking that the output of the C++ compiler is
executable.
Another advantage of this is that if we're not running the test suite,
we can do a more traditional cross-build where running host-architecture
executables is impossible, which doubles as a way to prove that this
still works.
Signed-off-by: Simon McVittie <smcv@collabora.com>
On Debian 12, this is necessary to get libclang-rt-14-dev (which
contains the headers for LeakSanitizer) without hard-coding the clang
major version.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This has been noted to be unreliable (dbus#509) and we now have more
realistic test coverage on actual Windows.
I'm marking these CI jobs to do the build but not run the tests,
instead of skipping them completely, because having coverage for a
successful build on mingw-w64 (32-bit, 64-bit) bit × (release, debug)
does still seem like a useful thing for us to have.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we're building on Unix with the message bus and tools enabled, then
we need to compile dbus-launch before we can expect this test to pass.
Continuation of commit 55e60abe "test: add missing test dependencies".
Signed-off-by: Simon McVittie <smcv@collabora.com>
CMake has previously installed the api documentation in the api/
subdirectory, but api/html is required to correspond to the link
in the generated index file (index.html).
Fix#519
