Por que o sudo -i não configura XDG_RUNTIME_DIR para o usuário de destino?

Question

XDG_RUNTIME_DIR é necessário para que systemctl --user funcione.

Eu configurei o servidor ubuntu 16.04 para executar sessões do usuário systemd. Agora, ao tentar administrá-los, descubro que, ao alterar um usuário por meio de sudo -u $user -i ou mesmo su - $user , o ambiente não tem XDG_RUNTIME_DIR set, evitando que systemctl --user funcione. No entanto, quando eu ssh direto para esse usuário, ele está definido corretamente.

Se eu entendi a documentação corretamente, isso deve ser definido por libpam-systemd ao criar a sessão do usuário. A fatia do usuário é iniciada corretamente, pois o diretório ao qual XDG_RUNTIME_DIR deve apontar ( /run/users/$uid ) existe. Estou hesitante em apenas codificá-lo, digamos, .bash_profile , porque isso parece ser hacky (embora esteja funcionando), quando o pam deve estar cuidando disso.

Eu posso, claro, adicionar XDG_RUNTIME_DIR a env_keep em sudoers , mas isso preservaria o ambiente do usuário sudoing, que não é o que eu quero. Eu quero o ambiente do usuário target .

O que eu realmente estou querendo saber é como a sessão está configurada corretamente com ssh , mas não com su ou sudo -i ?

    

Answer 1

Eu repliquei este problema no meu sistema Fedora 25.

Encontrei uma condição muito suspeita no código-fonte. link Parece que foi escrito com normal sudo em mente, mas não sudo -u non-root-user .

machinectl shell --uid=non-root-user funcionou como você pediu.

systemd-run não parece funcionar como desejado, apesar da referência a ele na documentação do maquinário.

Alguns comandos machinectl não funcionam se você tiver habilitado o SELinux no momento, e esses comandos específicos não funcionaram para mim até que eu fiz setenforce 0 . No entanto, estou no meio de tentar soluções alternativas para que o machinectl funcione como eu quero que seja feito com o SELinux, por isso é possível que o meu mexer seja o que causa, e. machinectl shell para o tempo limite.

EDIT: Acho que esse código foi introduzido após discussão . E, aparentemente, su - / sudo -i poderia funcionar, mas ninguém o implementou (ainda).

    

Answer 2

What I'm really wondering, though, is how come the session is set up correctly with ssh, but not with su or sudo -i?

link

Sorry, but "su" is a tool for changing user identities and very few other process credentials temporarily. It's not a tool for opening a completely new login session. A new login session has a very well defined, pristine setup, not inheriting anything from any other session, but this is really not the case for "su" uid changes: most of the execution environment is inherited over, in numerous and non-obvious ways, for example MAC contexts, audit contexts, cgroup contexts, namespace contexts, scheduling, timer granularity, …

if you want a full new session, use something like "machinectl login" or "machinectl shell", which will actually get your a fully clean, independent, detach environment, with no hidden process properties leaking from where you call it into it.

logind sessions are mostly bound to the audit session concept, and audit sessions remain unaffected by "su", in fact they are defined to be "sealed off", i.e. in a way that if a process entered a session once, it will always stay with it, and so will its children, i.e. the only way to get a new session is by forking off something off PID 1 (or something similar) that never has been part of a session.

Or to say this differently: the stuff you invoke through "su" will show up just fine in "loginctl", however, it remains part of your original session, you logged in originally. You can verify that by invoking "loginctl status" on the original session's ID (which you can see through echo $XDG_SESSION_ID)