On Do, 23.11.17 22:56, Jeff Solomon (jsolomon8...@gmail.com) wrote:

> Hi,
> More questions about the systemd user service.
> Inside a script running as root, I want to control another user's service.
> I have found two ways to do this:
>     systemd-run -t --setenv=XDG_RUNTIME_DIR=/run/user/<uid> --uid=<uid>
> systemctl --user ...
> or:
>     su -l <username> -c "XDG_RUNTIME_DIR=/run/user/<uid> systemctl --user
> ..."
> Both work.
> If there a better way to do this?
> My distros aren't recent enough to include "machinectl shell" but is that
> the recommended way now?
>     machinectl --uid=<uid> shell /bin/systemctl --user ...
> Perhaps there is not enough demand to justify it, but I would love if the
> systemctl command itself had a way to specify that it should communicate
> with a different user's service rather than system service or the calling
> user's service. Something like:
>     systemctl --uid=<uid> --user ..
> would be awesome.

Hmm, sorry, but this is something we'll are unlikely to support in any
special way. Making privileged code a client of unpriveled user code
like this makes me feel very uncomfortable. Privileged code really
should not transition and block on unprivileged user code likes
this. Philosophically it has this feeling of being the wrong way
round: the unpriv code should ask the priv code what it should do, it
shouldn't be the priv code that asks the unpriv code, in any blocking
way... I mean, the unpriv code can ultimately do whatever it wants,
and priv code should not block on that for good. It's simply the wrong
way round to design such a system, if you follow what i mean.

Usually most usecase like that are better solved by making things
asynchronous notifier based, and make the unpriv code just react to
notifications, instead of synchronous call-ins...


Lennart Poettering, Red Hat
systemd-devel mailing list

Reply via email to