summaryrefslogtreecommitdiff
path: root/src/stdio-bridge
diff options
context:
space:
mode:
authorLennart Poettering <lennart@poettering.net>2020-12-14 13:21:58 +0100
committerLennart Poettering <lennart@poettering.net>2020-12-15 18:00:15 +0100
commit1b630835dff5e13046dfd266629f8ff244dc7fb0 (patch)
tree6de6bca5a974b38eb68ac377c5512e6564d60637 /src/stdio-bridge
parent1ca37419b13b836d7fb2b9815d5efb6dccc62134 (diff)
downloadsystemd-1b630835dff5e13046dfd266629f8ff244dc7fb0.tar.gz
sd-bus: add API for connecting to a specific user's user bus of a specific container
This is unfortunately harder to implement than it sounds. The user's bus is bound a to the user's lifecycle after all (i.e. only exists as long as the user has at least one PAM session), and the path dynamically (at least theoretically, in practice it's going to be the same always) generated via $XDG_RUNTIME_DIR in /run/. To fix this properly, we'll thus go through PAM before connecting to a user bus. Which is hard since we cannot just link against libpam in the container, since the container might have been compiled entirely differently. So our way out is to use systemd-run from outside, which invokes a transient unit that does PAM from outside, doing so via D-Bus. Inside the transient unit we then invoke systemd-stdio-bridge which forwards D-Bus from the user bus to us. The systemd-stdio-bridge makes up the PAM session and thus we can sure tht the bus exists at least as long as the bus connection is kept. Or so say this differently: if you use "systemctl -M lennart@foobar" now, the bus connection works like this: 1. sd-bus on the host forks off: systemd-run -M foobar -PGq --wait -pUser=lennart -pPAMName=login systemd-stdio-bridge 2. systemd-run gets a connection to the "foobar" container's system bus, and invokes the "systemd-stdio-bridge" binary as transient service inside a PAM session for the user "lennart" 3. The systemd-stdio-bridge then proxies our D-Bus traffic to the user bus. sd-bus (on host) → systemd-run (on host) → systemd-stdio-bridge (in container) Complicated? Well, to some point yes, but otoh it's actually nice in various other ways, primarily as it makes the -H and -M codepaths more alike. In the -H case (i.e. connect to remote host via SSH) a very similar three steps are used. The only difference is that instead of "systemd-run" the "ssh" binary is used to invoke the stdio bridge in a PAM session of some other system. Thus we get similar implementation and isolation for similar operations. Fixes: #14580
Diffstat (limited to 'src/stdio-bridge')
-rw-r--r--src/stdio-bridge/stdio-bridge.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/stdio-bridge/stdio-bridge.c b/src/stdio-bridge/stdio-bridge.c
index 81d50717b2..1b7c3feaea 100644
--- a/src/stdio-bridge/stdio-bridge.c
+++ b/src/stdio-bridge/stdio-bridge.c
@@ -121,7 +121,7 @@ static int run(int argc, char *argv[]) {
return log_error_errno(r, "Failed to allocate bus: %m");
if (arg_transport == BUS_TRANSPORT_MACHINE)
- r = bus_set_address_system_machine(a, arg_bus_path);
+ r = bus_set_address_machine(a, false, arg_bus_path);
else
r = sd_bus_set_address(a, arg_bus_path);
if (r < 0)