So this question has been already asked, but the answers there do not solve the issue of environment variables. Is there a way to be switch users completely such that the pam-systemd is called and every automatic XDG environment variable is set?

Compare the following

The following options start by turning on a powered down machine.

Option 1 Log in as root. Type the following within the shell:

su -l username

Option 2 Log in as username. Type the following within the shell:


You see that there is a difference. Option 1 yields /run/user/0 despite the change in users using su (switch user), because the pam_systemd module was not called during the switch. Option 2 yields /run/user/$(id -u) as expected. Now I could simply log off by typing exit until the machine prompts me for a login again and login as the desired user. Is there another way to do it? Using sudo instead of su does not help.

Is it the right way to do echo "XDG_RUNTIME_DIR=$(id -u) >> .bash_profile", because .bash_profile gets executed by su?

  • It will be highly insecure, so you should create a script which which store the required environment variable, than switch the user and then set the environment variable. But this should be done with care, and only for few secure variables. But usually it mean that one is doing the things in the wrong way. Reframe and you will find a easier solution. – Giacomo Catenazzi Mar 30 '17 at 13:20
  • @GiacomoCatenazzi Oh really? Could you please explain what about it would be insecure? I do not want to compromise security! Or maybe just provide a link to the information I seek. – Jonathan Komar Mar 30 '17 at 13:25
  • Ok, maybe it is exaggerated. User 1 can force overwrite any file of user 2, but if you are user1 and user2, such vulnerabilities are minor. But if you create two users, it means to have them split. In any case user 2 and user 1 have different permissions to XDG directories, so you can have strange things. And possibly program will not expect that other user will modify "own" files. – Giacomo Catenazzi Mar 30 '17 at 13:34

I think the answer might be to just use login instead of su to ensure that the pam_systemd module gets executed and sets the variables, and also as Giacomo pointed out, to ensure that only one user (more than one like in the spawned su subprocess scenario) can change files within that environment.

The danger of su can be visually represented on a system using systemd like this:

using su

root  -systemd
root    -login # calls pam_systemd and sets XDG_RUNTIME_DIR among others
user1     -bash
user1       -su
user2         -bash # user1 has access to spawned subprocesses?

using login

root -systemd
root   -login # calls pam_systemd and sets XDG_RUNTIME_DIR among others
user2     -bash

Also loginctl does not register the user encapsulated by the su/bash subprocess, because the user is never registered with systemd-logind.service by pam_systemd.mod.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.