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>
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>
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>
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
D-Feet is no longer maintained and its closest replacement, as mentioned
in the D-Feet page https://wiki.gnome.org/Apps/DFeet, is d-spy.
The project description doesn't need to be updated because d-spy
provides the same set of features that D-Feet had.
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
gitlab.fd.o/bustle/bustle points to the old archived project. The new
version has been rewritten in Rust and is now hosted at
gitlab.gnome.org/World/bustle
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
Make D-Bus implementations return a file descriptor
pinning the process as part of the credentials on
platforms that implement such concept, like Linux.
Pinning the process allows to defend against PID
reuse attacks, making authentication by
service/cgroup possible.
Signed-off-by: Luca Boccassi <bluca@debian.org>
The original code of 'ProgressNotification' had a wrong closing tag,
which should use '</signal>' instead of '</method>'
Signed-off-by: Yen-Chin, Lee <coldnew.tw@gmail.com>
The full license texts are not added because they were already
added in a previous commit.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
see #394
These files are licensed under the GPL only, without the AFL dual-license
of most of the dbus codebase.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Co-authored-by: Ralf Habacker <ralf.habacker@freenet.de>
The interoperable address is unix:path=/var/run/dbus/system_bus_socket.
However, in most (perhaps all) current Linux distributions, /var/run
is guaranteed to be a symbolic link to /run, and using the path in /run
has some advantages (particularly if automounters are used).
Implementations that intend to be interoperable are not required to
listen on exactly /var/run/dbus/system_bus_socket, as long as clients
that connect to that socket will work correctly. Similarly, clients
are not required to connect to exactly /var/run/dbus/system_bus_socket,
as long as the overall system (consisting of the client and the OSs
that it supports) ensures that it ends up connecting to the same
well-known system bus that is available at
/var/run/dbus/system_bus_socket.
Because of the Unix conventions for how software installs into a prefix,
building a D-Bus implementation with its default build-time
configuration options will not necessarily result in an interoperable
system bus. The system bus is normally shipped by OS distributors,
who should ensure that they have configured it in a way that is
interoperable.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/180
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it possible for projects to incorporate D-Bus as a CMake sub-project in a larger CMake project.
Before this PR, doing so would result in many errors.
This is because CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR would point to directories above the D-Bus project.
Using paths relative to the project directory, PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR, corrects for this.
The comment refers to the nul-padding of sockaddr_un member sun_path and
using an addrlen of sizeof(sockaddr_un). There is not much need to
document an old now "broken" behaviour.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Older versions of yelp-build like the one in Debian 11 do not allow
permuting arguments, so all options (in this case -o) must appear
before all positional parameters.
Signed-off-by: Simon McVittie <smcv@collabora.com>
