1b630835df
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 |
||
---|---|---|
.github | ||
.lgtm/cpp-queries | ||
.mkosi | ||
catalog | ||
coccinelle | ||
docs | ||
factory/etc | ||
hwdb.d | ||
man | ||
modprobe.d | ||
network | ||
po | ||
presets | ||
rules.d | ||
semaphoreci | ||
shell-completion | ||
src | ||
sysctl.d | ||
sysusers.d | ||
test | ||
tmpfiles.d | ||
tools | ||
travis-ci | ||
units | ||
xorg | ||
.clang-format | ||
.ctags | ||
.dir-locals.el | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
.lgtm.yml | ||
.mailmap | ||
.travis.yml | ||
.vimrc | ||
.ycm_extra_conf.py | ||
LICENSE.GPL2 | ||
LICENSE.LGPL2.1 | ||
Makefile | ||
NEWS | ||
README | ||
README.md | ||
TODO | ||
azure-pipelines.yml | ||
configure | ||
meson.build | ||
meson_options.txt | ||
mkosi.build | ||
zanata.xml |
README.md
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.