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
We will need this to be able to shut down the container when its
creator vanishes.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Fix minor conflict]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354
If we're strict now, we can relax this later (either with a named
parameter or always); but if we're lenient now, we'll be stuck with it
forever, so be strict.
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
This means we can accept connections on the new socket. For now, we
don't process them and they get closed.
For the system bus (or root's session bus, where the difference is
harmless but makes automated testing easier), rely on system-wide
infrastructure to create /run/dbus/containers. The upstream dbus
distribution no longer contains integration glue for non-systemd boot
systems, but downstreams that maintain a non-systemd boot system and are
interested in the Containers interface should create /run/dbus/containers
during boot.
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 still don't actually create a DBusServer for incoming connections
at this point, much less accept incoming connections.
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
In particular, we now fail early if we can't extract the file
descriptor, or if there are named parameters (none are supported yet).
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
So far it only exercises SupportedArguments.
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
For now, this is considered to be a privileged operation, because the
resource-limiting isn't wired up yet. It only contains the bare minimum
of API.
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 aren't *that* verbose, so it seems OK to print them all the time,
not just in the needlessly spammy verbose mode.
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>
Tests that brute-force OOM code paths can be rather slow.
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>
test_object_try_whatever() now has libdbus-like OOM handling,
while test_object_whatever() has GLib-like OOM handling. This is
because an overwhelming majority of the callers of these functions
either didn't check for OOM anyway, or checked for it but then
aborted. In the uncommon case where we do care, we can use the _try_
version.
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>
If _dbus_loop_queue_dispatch fails with OOM, we'd try to free cd,
while cd is already owned by the connection's timeout functions.
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>
