© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
I have 32 machines under my control and all of them are experiencing the same issue. I have found some email archives from the debian project and I have found some documentation that I think could be helpful.
trying to run su with (-, -l,--login) or on its own causes the issue. su does invoke a call out to pam_systemd.so (according to docs and logs), but systemd will see that the process (su in this case) is already in a existing session (the session of the user you are trying to switch from) and it will exit out failing to make a new session for the user because it is reading that the sessions for the origin user exists instead of creating a logind sessions for the destination user. If you use ssh and login on the loop back interface everything works out fine, but the system I am using is being run by a daemon that is run as root and needs to switch to a desired user to start up x sessions for the users. We just moved away from a ssh key system for the remote server's because it was becoming too cumbersome to debug especially as we plan to expand to more machines.
I read that it is possibly a POSIX standard that declares that logind is not supposed to be called when calling su and that is why this behavior exists, but if that is the case why does the desired functionality (the starting of logind and setting of XDG_SESSION_ID and XDG_SESSION_ID environment variables) exist in Ubuntu 14.04.x?
If this is determined to not be a bug and expected functionality from here on out what reasonable work around do you suggest to allow a program running as root either call su to become a new user and start an x server or use setuid() in a C program and start a new x server for the user with the aforementioned desired variables intact?
If this is determined to be a bug and it won't be fixed in 16.04.3++ what work around do you suggest be used to achieve the desired result?
I would like to strongly suggest that this be accepted as a bug and rejected as desired behavior, switching the user should go through the PAM authentication and startup and required services for the user. su - "user" should yield a shell the equivalent of ssh "user" if they both are using PAM they should yield the same result.
debian explination:
https:/
debian pseudo patch:
https:/
xinit work around (old but good reading material):
http://
ubuntu forums post from 2012-2013 with similar issue:
https:/