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

XDG_RUNTIME_DIRé necessário para systemctl --usertrabalhar.

Eu configurei o servidor ubuntu 16.04 para executar as sessões do usuário systemd. Agora, ao tentar administrá-los, acho que, ao alterar um usuário via sudo -u $user -iou mesmo su - $user, o ambiente não foi XDG_RUNTIME_DIRdefinido, impedindo o systemctl --usertrabalho. No entanto, quando eu sshdireto para esse usuário, ele está definido corretamente.

Se eu entendi a documentação corretamente, isso deve ser definido libpam-systemdao criar a sessão do usuário. A fatia do usuário é iniciada corretamente, pois o diretório para o qual XDG_RUNTIME_DIRdeve apontar ( /run/users/$uid) existe. Eu hesito em codificá-lo, digamos, .bash_profileporque isso parece hacky (embora funcione), quando o pam deveria cuidar disso.

Eu posso, é claro, adicionar XDG_RUNTIME_DIRa env_keepno sudoers, mas que seria apenas preservar o ambiente do usuário sudoing, que não é o que eu quero. Eu quero o ambiente do usuário de destino .

O que realmente estou me perguntando é como é que a sessão é configurada corretamente com ssh, mas não com suou sudo -i?

Eu repliquei esse problema no meu sistema Fedora 25.

Eu encontrei uma condição muito suspeita no código fonte. https://github.com/systemd/systemd/blob/f97b34a/src/login/pam_systemd.c#L439 Parece que foi escrito com o normal sudoem mente, mas não sudo -u non-root-user.

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

systemd-run não pareceu funcionar como desejado, apesar da referência a ele na documentação do machinectl.

Alguns comandos machinectl não funcionam se você ativou o SELinux no momento, e esses comandos específicos não funcionaram para mim até eu setenforce 0. No entanto, estou no meio de tentar soluções alternativas para fazer com que o machinectl funcione, como eu quero que ele faça com o SELinux, então é possível que minhas brincadeiras sejam o que causa, por exemplo, o machinectl shelltempo limite.

Edição: Eu acho que este código foi introduzido após esta discussão . E aparentemente su -/ sudo -ipoderia ser feito para funcionar, mas ninguém o implementou (ainda).

No entanto, o que realmente estou pensando é como é que a sessão é configurada corretamente com ssh, mas não com su ou sudo -i?

https://github.com/systemd/systemd/issues/7451#issuecomment-346787237

Desculpe, mas "su" é uma ferramenta para alterar identidades de usuário e muito poucas outras credenciais de processo temporariamente. Não é uma ferramenta para abrir uma sessão de login completamente nova. Uma nova sessão de logon possui uma configuração primitiva muito bem definida, que não herda nada de nenhuma outra sessão, mas esse não é realmente o caso de alterações "su" uid: a maior parte do ambiente de execução é herdada em numerosas e não óbvias maneiras, por exemplo, contextos MAC, contextos de auditoria, contextos de cgroup, contextos de namespace, planejamento, granularidade do temporizador,…

se você quiser uma nova sessão completa, use algo como "machinectl login" ou "machinectl shell", que realmente proporcionará um ambiente totalmente limpo, independente e desanexado, sem que ocorram propriedades ocultas do processo de onde você o chama.

as sessões de logind geralmente estão vinculadas ao conceito da sessão de auditoria, e as sessões de auditoria permanecem inalteradas por "su"; na verdade, são definidas como "seladas", ou seja, de uma maneira que, se um processo entrar em uma sessão uma vez, permanecerá sempre com ele, e seus filhos também, ou seja, a única maneira de obter uma nova sessão é obter algo fora do PID 1 (ou algo semelhante) que nunca fez parte de uma sessão.

Ou para dizer de outra maneira: as coisas que você invoca através de "su" aparecerão muito bem em "loginctl", no entanto, ele permanece parte da sua sessão original, você fez o login originalmente. Você pode verificar isso invocando "status loginctl" no ID da sessão original (que pode ser visualizado através do eco $ XDG_SESSION_ID)