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