1

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
echo $XDG_RUNTIME_ENV

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

echo $XDG_RUNTIME_ENV

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?

Community
  • 1
Jonathan Komar
  • 6,424
  • 7
  • 35
  • 53
  • 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

2 Answers2

1

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.

Jonathan Komar
  • 6,424
  • 7
  • 35
  • 53
1

If you have root/sudo access and need to fully impersonate another user without knowing or changing their password, if your Linux distro is modern enough to support it you should use:

sudo machinectl shell --uid usernameGoesHere

This actually creates a session and gives you a login shell with the user's normal environment (including the variables starting with $XDG_), so everything should look and work exactly the same as if the user logged on normally. This is superior to any su or sudo incantations I've seen in replicating all aspects of a regular user login, but without their login credentials.

Needless to say, this is super helpful as a sysadmin for troubleshooting an issue that a user is experiencing, or for running applications on behalf of another user that rely on the environment such as podman.

PolyTekPatrick
  • 151