[systemd-devel] what is the best way to connect to another user's service (when root)?

[Jeff Solomon]

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.






On Fri, Nov 24, 2017 at 5:05 AM, Lennart Poettering <lennart at poettering.net>
wrote:

> On Do, 23.11.17 22:56, Jeff Solomon (jsolomon8080 at 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
>
> --
> Lennart Poettering, Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20171124/3fb34a95/attachment.html>