On Mar 25, 2014 2:33 PM, "David Schmitt" <<a href="mailto:david@dasz.at">david@dasz.at</a>> wrote: > > On 25.03.2014 12:59, "Jóhann B. Guðmundsson" wrote: >> >> >> On 03/25/2014 08:42 AM, David Schmitt wrote: >>> >>> If that is a better supported way of achieving my goal of giving a set >>> of users the power to manage their own services... >> >> >> Can you further explain why you want to do that? >> >> What's the use case here for embedded/server/desktop? >> >> What are you trying to achieve? > > > I've built a small shared hosting setup where I'm managing customer's applications with private nginx and (php|mono|...)-fastcgi instances. This allows the customers to flexibly configure application instances using the power of systemd, while everything is still running under the UID of the customer. > > Currently all customer services are running under a --user instance, which I've got to run by enabling the proper user@.service and using enable-linger on the user. > > Finally I wanted to delegate service restart privileges to other users within a customer, but stumbled upon sudo's peculiar behaviour. Currently I'm working around this with a sudo/su combination. > > The more I think about it, the more I realize I might be happier with some kind of ultra-thin containerization of customers. That would also reduce information leakage between customers (running procs, etc). On the other hand, the current solution with --user is pretty simple all around, so adding a container layer might be too much complexity for the gain. > > >> What behavior do you want? > > > The requirement I initially asked about, is this: given the proper sudoers entry allow user alice to run > > $ sudo -u bob systemctl --user reload nginx.service > > and have it work. My analysis ended at the point that even when using pam_systemd, sudo does not provide the proper XDG_SESSION* environment variables to the executed command. The only important variable here is XDG_RUNTIME_DIR, as systemctl looks there for the user instance's private socket. I think in later versions it *is* exported by pam_systemd – that your example has the username and not the UID in this variable shows that it's a quite old systemd version. The other two variables identify the login session – XDG_SESSION_ID is set by pam_systemd to the logind session ID (for scripts and informational purposes mostly), and XDG_SESSION_COOKIE comes from ConsoleKit (which actually depends on the variable). I am not sure why the latter two are set at all in your case – 'su' probably should not create a new login session, it should remain in the previous one. On the other hand, there were a few threads about just how much 'su' and 'sudo' are meant to change...It also depends on whether su/sudo are invoked *from* within an existing session (they should always be). -- Mantas Mikulėnas <<a href="mailto:grawity@gmail.com">grawity@gmail.com</a>>