[systemd-devel] sudo -u app_user systemctl --user

[Mantas Mikulėnas]

On Mar 25, 2014 2:33 PM, "David Schmitt" <david at dasz.at> 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 at .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 <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140325/9600f3f7/attachment.html>