Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317
Reviewed-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=100317
Reviewed-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=100317
Reviewed-by: Philip Withnall <withnall@endlessm.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
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
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 39262d0a29.
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>
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=104577
Reviewed-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=103914
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: Alexander Larsson <alexl@redhat.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
This lets ordinary users create a limited number of app-containers
on the system bus.
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
These will be enforced in subsequent commits.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Fix whitespace]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354
After the container instance is removed, the method should not work.
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
These connections are not to a container server.
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
These are debugging interfaces, which are essentially read-only.
By default, Verbose is not available on the system bus at all and
Stats is only available to uid 0, but both are available on the
session bus, and they can be allowed for other uids by configuring
the system bus.
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
We can relax AddServer() from PRIVILEGED to NOT_CONTAINERS when we've
put resource limits in place, although for now it must remain
PRIVILEGED because it uses up resources.
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
We should prevent containers from trying to put a container in our
container so we can sandbox while we sandbox. The implementation doesn't
actually have any concept of nesting or layering, so that would potentially
be privilege escalation.
At the moment, this is just prevented by METHOD_FLAG_PRIVILEGED. When we
remove that flag (after we've introduced better resource limits), we can
specifically restrict this method to not be called by containers
instead. This test will make sure we do.
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
Even if the uid matches, a contained app shouldn't count as the owner
of the bus.
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
On the system bus, that would be a denial of service, assuming we
relax the access-control from METHOD_FLAG_PRIVILEGED to a new
METHOD_FLAG_NOT_CONTAINERS later.
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
We will eventually want to have other ways to signal that a
container server should stop listening, so that the container manager
doesn't have to stay on D-Bus (fd-passing the read end of a pipe
whose write end will be closed by the container manager has been
suggested as easier to deal with for Flatpak/Bubblewrap), but for
now we're doing the simplest possible thing.
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
