Discussion:
what is the best way to connect to another user's service (when root)?
(too old to reply)
Jeff Solomon
2017-11-24 06:56:34 UTC
Permalink
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.

Jeff
Lennart Poettering
2017-11-24 13:05:49 UTC
Permalink
Post by Jeff Solomon
Hi,
More questions about the systemd user service.
Inside a script running as root, I want to control another user's service.
systemd-run -t --setenv=XDG_RUNTIME_DIR=/run/user/<uid> --uid=<uid>
systemctl --user ...
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
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
--
Lennart Poettering, Red Hat
Jeff Solomon
2017-11-24 17:42:45 UTC
Permalink
On the one hand, I understand your point. On the other hand, there are
three other ways of doing this:

systemd-run -t --setenv=XDG_RUNTIME_DIR=/run/user/<uid> --uid=<uid>
systemctl --user ...
su -l <username> -c "XDG_RUNTIME_DIR=/run/user/<uid> systemctl --user"
machinectl --uid=<uid> shell /bin/systemctl --user ...

(I'm assuming the last way actually works. Does it?)

So I thought that my suggestion was an even cleaner way to accomplish the
same thing. I get that you don't want priv code to depend on unpriv code
but systemctl is a command line tool. It's up to the user if they want to
run it that way.
Post by Jeff Solomon
Post by Jeff Solomon
Hi,
More questions about the systemd user service.
Inside a script running as root, I want to control another user's
service.
Post by Jeff Solomon
systemd-run -t --setenv=XDG_RUNTIME_DIR=/run/user/<uid> --uid=<uid>
systemctl --user ...
su -l <username> -c "XDG_RUNTIME_DIR=/run/user/<uid> systemctl
--user
Post by Jeff Solomon
..."
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
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
--
Lennart Poettering, Red Hat
Loading...