Dlaczego sudo -i nie ustawia XDG_RUNTIME_DIR dla użytkownika docelowego?

XDG_RUNTIME_DIRjest niezbędny systemctl --userdo pracy.

Skonfigurowałem serwer Ubuntu 16.04 do uruchamiania sesji użytkownika systemd. Teraz, kiedy próbuję nimi zarządzać, stwierdzam, że kiedy zmieniam użytkownika za pośrednictwem sudo -u $user -ilub nawet su - $user, środowisko nie ma XDG_RUNTIME_DIRustawionego, uniemożliwiającego systemctl --userdziałanie. Jednak po przejściu sshbezpośrednio do tego użytkownika jest ono ustawione poprawnie.

Jeśli dobrze rozumiem dokumentację, należy ją ustawić libpam-systemdpodczas tworzenia sesji użytkownika. Wycinek użytkownika jest uruchamiany poprawnie, ponieważ istnieje katalog, do którego XDG_RUNTIME_DIRnależy point ( /run/users/$uid). Waham się, żeby po prostu zakodować go, powiedzmy, .bash_profileponieważ wydaje się to hack (choć działa), kiedy pam powinien się tym zająć.

Mogę oczywiście dodać XDG_RUNTIME_DIRdo env_keepw sudoers, ale to po prostu zachować środowisko użytkownika sudoing, która nie jest to, co chcę. Chcę środowiska docelowego użytkownika.

Zastanawiam się jednak, dlaczego sesja jest poprawnie skonfigurowana z ssh, ale nie z sulub sudo -i?

Replikowałem ten problem na moim systemie Fedora 25.

Znalazłem bardzo podejrzany warunek w kodzie źródłowym. https://github.com/systemd/systemd/blob/f97b34a/src/login/pam_systemd.c#L439 Wygląda na to, że został napisany z sudomyślą o normalności , ale nie sudo -u non-root-user.

machinectl shell --uid=non-root-user działało tak, jak prosiłeś.

systemd-run nie wydaje się działać zgodnie z oczekiwaniami, pomimo odniesienia do tego w dokumentacji machinectl.

Niektóre polecenia machinectl nie działają, jeśli w tej chwili włączyłeś SELinux, a te specyficzne polecenia nie działały dla mnie, dopóki nie zrobiłem tego setenforce 0. Jednak jestem w trakcie prób obejścia tego problemu, aby machinectl działał tak, jak chcę, aby napisał SELinux, więc możliwe jest, że moje skrzypienie jest przyczyną np machinectl shell. Przekroczenia limitu czasu.

EDYCJA: Myślę, że ten kod został wprowadzony po tej dyskusji . I najwyraźniej su -/ sudo -imożna by go uruchomić, ale nikt go nie wdrożył (wciąż).

Zastanawiam się jednak, dlaczego sesja została poprawnie skonfigurowana z ssh, ale nie z su lub sudo -i?

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

Przepraszamy, ale „su” jest narzędziem do tymczasowej zmiany tożsamości użytkownika i bardzo niewielu innych danych uwierzytelniających proces. To nie jest narzędzie do otwierania zupełnie nowej sesji logowania. Nowa sesja logowania ma bardzo dobrze zdefiniowaną, nieskazitelną konfigurację, nie dziedziczy niczego z żadnej innej sesji, ale tak naprawdę nie ma to miejsca w przypadku zmian „su”: ​​większość środowiska wykonawczego jest dziedziczona, w wielu i nieoczywistych sposoby, na przykład konteksty MAC, konteksty audytu, konteksty grupy, konteksty przestrzeni nazw, planowanie, szczegółowość timera,…

jeśli chcesz mieć zupełnie nową sesję, użyj czegoś takiego jak „login machinectl” lub „shell machinectl”, który faktycznie zapewni w pełni czyste, niezależne środowisko odłączania, bez ukrytych właściwości procesu wyciekających z miejsca, w którym go wywołujesz.

sesje logind są w większości związane z koncepcją sesji audytu, a sesje audytu pozostają nienaruszone przez „su”, w rzeczywistości są one zdefiniowane jako „zamknięte”, tj. w taki sposób, że jeśli proces raz wejdzie w sesję, zawsze pozostanie wraz z nim, podobnie jak jego dzieci, tj. jedynym sposobem na uzyskanie nowej sesji jest wyrwanie czegoś z PID 1 (lub czegoś podobnego), który nigdy nie był częścią sesji.

Innymi słowy: rzeczy, które wywołujesz przez „su”, będą się dobrze wyświetlać w „loginctl”, jednak pozostają częścią twojej oryginalnej sesji, po zalogowaniu się. Możesz to sprawdzić, wywołując „loginctl status” na pierwotnym identyfikatorze sesji (co można zobaczyć poprzez echo $ XDG_SESSION_ID)