Bug#727645: Please see bug #668890

> I don't know if su works differently when using systemd and not sysvinit
> and makes this problem appear only when using systemd.

Ok, I don't see that behavior here (I'm not using systemd as init system but I
have it installed), start-stop-daemon and /bin/su use the setuid syscall,
but su uses pam, so, its related to the pam-session part. I still don't
understand why is it different if you are using a systemd init system or not.

I could be wrong but I think it's due to pam_systemd.

quote from http://www.freedesktop.org/software/systemd/man/pam_systemd.html:

"pam_systemd registers user sessions with the systemd login manager systemd-logind.service(8), and hence the systemd control group hierarchy.

On login, this module ensures the following:

1. If it does not exist yet, the user runtime directory /run/user/$USER is created and its ownership changed to the user that is logging in.

2. The $XDG_SESSION_ID environment variable is initialized. If auditing is available and pam_loginuid.so run before this module (which is highly recommended), the variable is initialized from the auditing session id (/proc/self/sessionid). Otherwise an independent session counter is used.

3. A new systemd scope unit is created for the session. If this is the first concurrent session of the user, an implicit slice below user.slice is automatically created and the scope placed in it. In instance of the system serviceuser@.service which runs the systemd user manager instance."

The fix to the dirmngr initscript that Maurizio proposes in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668890#60 (change su to start-stop-daemon) fixed the problem for me.

Now that systemd will be the default init system in Jessie this should be solved in one way or another.

Thanks,

Sami