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

David Schmitt david at dasz.at
Thu Mar 20 04:43:21 PDT 2014


Hi,

for a hosting project, I'd like to enable some users to control the user 
session of an application user.

Configuring and running the applications under the app user already 
works great.

The straightforward way in my mind would have been to enable sudoing 
from the personal accounts into the app user, allowing to run "systemctl 
--user ..." Sadly, this does not work out, as I've not found a way to 
get sudo to enter the app user's xdg session.

Curiously, using su- this would work. I'm wondering whether I've 
overlooked some configuration bit or whether sudo is just doing things 
differently enough, so that I'll have to use su- instead and create some 
kind of wrapper script for safety.

# su works
> personal at testagent:~$ sudo -kn su - app_user -c 'systemctl --user status nginx.service'
> nginx.service - The nginx HTTP and reverse proxy server
> 	  Loaded: loaded (/srv/dasz/home/app_user/.config/systemd/user/nginx.service; enabled)
> 	  Active: failed (Result: exit-code) since Thu, 20 Mar 2014 07:49:54 +0100; 2h 17min ago
> 	 Process: 17746 ExecStartPre=/usr/sbin/nginx -c /srv/dasz/etc/nginx/nginx.conf -t (code=exited, status=1/FAILURE)
> 	  CGroup: name=systemd:/user/app_user/shared/systemd-17741/nginx.service
>
# sudo doesn't
> personal at testagent:~$ sudo -kn -u app_user systemctl --user status nginx.service
> Failed to get D-Bus connection: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
> personal at testagent:~$

IIUIC, systemctl's behaviour is caused by this difference:
> personal at testagent:~$ sudo -kn su - app_user -c env | grep ^XDG
> XDG_SESSION_ID=c19
> XDG_SESSION_COOKIE=1f9ce2afe379e46cdfedb64153259313-1395305911.233556-949665988
> XDG_RUNTIME_DIR=/run/user/app_user
> personal at testagent:~$ sudo -knu app_user env | grep ^XDG
> personal at testagent:~$

I've also tried replacing sudo's pam config with su's, because the 
former is only creating noninteractive sessions by default, but that 
didn't change the behaviour.

Environment: Debian stable
> # dpkg -l login sudo systemd libpam-systemd
> ||/ Name                                                           Version                              Architecture
> +++-==============================================================-====================================-============
> ii  libpam-systemd:amd64                                           44-11+deb7u4                         amd64
> ii  login                                                          1:4.1.5.1-1                          amd64
> ii  sudo                                                           1.8.5p2-1+nmu1                       amd64
> ii  systemd                                                        44-11+deb7u4                         amd64
> #

I'm aware that this is not the current systemd version, but since I 
believe this is a actually problem on the sudo side, I hope that won't 
make a big difference.



Thanks for any hints you can provide.


Regards, David



More information about the systemd-devel mailing list