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 <lenn...@poettering.net>
wrote:
> 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
>
> --
> Lennart Poettering, Red Hat
>
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
