GitLab

Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588

Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588

Previously, USERID_HEX and USERNAME_HEX were both replaced by the hex
encoding of the numeric uid, something like 31303030 for "1000".
Now USERNAME_HEX is something like 736d6376 for "smcv". This is only
supported on Unix, but no authentication mechanisms use usernames on
Windows anyway.

This would require changing the tests that make use of USERNAME_HEX
if we had any, but we currently don't.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588

In the well-known system dbus-daemon, it's desirable to avoid looking
up non-numeric authorization identities in the user database, because
that could deadlock with NSS modules that directly or indirectly
require the system bus. Add a flag for whether the username will be
looked up in the userdb, and don't set that flag for EXTERNAL auth
(which is what we use on the system bus, and on the session bus
if not configured otherwise).

DBUS_COOKIE_SHA1 authentication is documented in terms of the
username (although in fact libdbus sends a numeric uid there too,
and GDBus only accepts a numeric uid) so continue to use the userdb
for that mechanism. DBUS_COOKIE_SHA1 needs to use the userdb on Unix
anyway, otherwise it won't find the user's home directory.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588

While I'm changing its signature anyway, I might as well fix a
long-standing FIXME.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588

The very common case for this function is that during AUTH EXTERNAL,
it receives a Unix uid encoded as an ASCII decimal integer. There is
no need to look up such uids in the system's user database
(/etc/password or NSS) when the only information we are going to use
from the DBusUserInfo struct is the uid anyway. This avoids taking
the lock and performing a potentially time-consuming NSS lookup.

This changes behaviour in one corner case: if a privileged process has
used one of the set*uid family of functions to set its effective uid
to a numeric uid that does not exist in the system's user database,
we would previously fail. Now, we succeed anyway: it is true to say
in the DBusCredentials that the process has uid 12345, even if uid
12345 does not correspond to any named user.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588

This provides the necessary information for services to make an
informed decision about how far they should trust the container type,
name and metadata fields.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104610

Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104610

On the session bus, the container type and name might be
uncontroversial, but on the system bus, it's questionable how far
they can be trusted: they're supplied by the initiator of the
per-container server, so we only have their word for it. While we
think about what to do about this, remove them, leaving only the
instance (which can be used to look up the rest).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104610

On the session bus, the container type and name might be
uncontroversial, but on the system bus, it's questionable how far
they can be trusted: they're supplied by the initiator of the
per-container server, so we only have their word for it.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104610

Signed-off-by: Simon McVittie <smcv@collabora.com>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>

This is an interpretation of the existing text. There are two plausible
ways a relaying server could interpret "must ignore [new] fields":
it could pass them through as-is, or it could delete them before
relaying. Until now, the reference implementation has done the former.

However, this behaviour is difficult to defend. If a server relays
messages without filtering out header fields that it doesn't
understand, then a client can't know whether the header field was
supplied by the server, or whether it was supplied by a (possibly
malicious) fellow client.

We can't introduce useful round-trip-reducing header fields like
SENDER_UNIX_USER_ID or SENDER_LINUX_SECURITY_LABEL until the
message bus filters them out, *and* provides a way for clients to
know for sure that it has done so. This is a step towards that
feature.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>

The Telepathy "Tubes" APIs are an example of a server that is not a
message bus, but makes use of the sender and destination fields to
provide broadly unique-connection-name-like semantics.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

These are defined by standard RFCs rather than by D-Bus. What
separates them from other standard mechanisms like PLAIN (RFC 4616)
is that in practice, D-Bus implementations support EXTERNAL,
DBUS_COOKIE_SHA1 and sometimes ANONYMOUS, but not PLAIN.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104224

We don't need to invent a MAGIC_COOKIE mechanism when we have a
perfectly good EXTERNAL.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104224

The SASL RFC requires that we do this. I had previously thought that
the D-Bus protocol on Unix requires the use of numeric user IDs,
but in fact the reference implementation will also accept usernames.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104224

The examples don't include an explanation, but the reference
implementation always sends the human-readable explanation, in both
directions.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104224

Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104224

Client-to-server auth commands expect a reply, whereas
server-to-client auth commands don't (the client is expected to send
another command that is valid in the new state, but it isn't really
a direct reply to the server-to-client command).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104224

Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104224

Having the text about the message stream in the documentation
of AUTH seemed rather odd, and made it likely to get out of sync
with the rest of the spec. Move it to the BEGIN section, remove
some duplication, and make it clearer that if the client pipelines
the fd-negotiation, the server is expected to send exactly one
reply per non-BEGIN command before switching to the D-Bus wire protocol.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104224

This was (hopefully) implicit in the protocol descriptions, but we
never actually said it. Do so.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104224

This reverts commit 39262d0a.
I'm reasonably sure the API for Container1 is going to change
incompatibly, so it isn't ready to be in the published spec yet.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

This snippet was already attempting to create /var/lib/dbus/machine-id,
but would fail on volatile or stateless systems where /var/lib/dbus/
did not already exist. systemd-tmpfiles automatically creates parent
directories for tmpfiles of type 'd', 'D', etc., but not for files
or symlinks (https://github.com/systemd/systemd/issues/7853).
Signed-off-by: Chris Lesiak <chris.lesiak@licor.com>
[smcv: Extended commit message to clarify why we need this]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104577Reviewed-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

We don't really need two parallel forms of punctuation, and in
particular DNS domain names only have one (hyphens). If we choose one
representation and deprecate the other, it makes the recommendation
clearer for app authors.

This reflects a similar change to the Desktop Entry Specification,
which uses D-Bus well-known names as app IDs. While hyphens are not a
problem for D-Bus well-known names or for freedesktop.org app IDs,
they create problems for adjacent APIs and specifications that want to
use a well-known name in a context where hyphens are not allowed.
Hyphens are not allowed in D-Bus object paths and interface names,
are only conditionally allowed in Flatpak app IDs (they can only
appear in the last element), and have a special syntactic role in
Freedesktop icon names.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103216
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103914Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: Alexander Larsson <alexl@redhat.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104265Reviewed-by: Simon McVittie <smcv@collabora.com>

Add experimental support for creating extra servers at runtime, to
be used by app containers like Flatpak or Snap. This API is still
subject to change and is not compiled in by default.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354