Почему sudo -i не устанавливает XDG_RUNTIME_DIR для целевого пользователя?

XDG_RUNTIME_DIRнеобходимо для systemctl --userработы.

Я настроил Ubuntu Server 16.04 для запуска пользовательских сессий systemd. Теперь, когда я пытаюсь их администрировать, я обнаруживаю, что при смене пользователя через sudo -u $user -iили даже su - $userсреду не XDG_RUNTIME_DIRустанавливают, мешая systemctl --userработать. Тем не менее, когда я sshпрямо в этом пользователе, он установлен правильно.

Если я правильно понимаю документацию, это должно быть установлено libpam-systemdпри создании сеанса пользователя. Пользовательский фрагмент запускается правильно, так как каталог, на который XDG_RUNTIME_DIRдолжен указывать ( /run/users/$uid), существует. Я не решаюсь просто сказать это жестко, скажем, .bash_profileпотому что это кажется хакерским (хотя и работает), когда Пэм должен позаботиться об этом.

Я могу, конечно, добавить XDG_RUNTIME_DIRк env_keepв sudoers, но это было бы просто сохранить окружающую среду пользователя sudoing, которая является не то , что я хочу. Я хочу среду целевого пользователя.

Что меня действительно интересует, так это то, почему сессия настроена правильно ssh, а не с suили sudo -i?

Я повторил эту проблему в моей системе Fedora 25.

Я обнаружил очень подозрительное состояние в исходном коде. https://github.com/systemd/systemd/blob/f97b34a/src/login/pam_systemd.c#L439 Выглядит так, как будто оно написано с нормой, sudoно не так sudo -u non-root-user.

machinectl shell --uid=non-root-user работал как вы просили.

systemd-run не работает должным образом, несмотря на ссылку в документации к machinectl.

Некоторые команды machinectl не работают, если вы в данный момент включили SELinux, и эти конкретные команды не работали до тех пор, пока я не включил их setenforce 0. Однако я нахожусь в процессе обходных путей, чтобы заставить машину работать, так как я хочу, чтобы она работала с SELinux, так что, возможно, моя возня - это то, что вызывает, например, machinectl shellтайм-аут.

РЕДАКТИРОВАТЬ: Я думаю, что этот код был введен после этого обсуждения . И, очевидно, su -/ sudo -iможно заставить работать, но никто не реализовал это (все еще).

Что меня действительно интересует, так это как получается, что сессия настроена правильно с помощью ssh, а не с su или sudo -i?

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

Извините, но "su" - это инструмент для временного изменения идентификационных данных пользователя и очень немногих других учетных данных процесса. Это не инструмент для открытия совершенно нового сеанса входа. Новый сеанс входа в систему имеет очень четко определенную, нетронутую настройку, не наследующую ничего от любого другого сеанса, но на самом деле это не относится к изменениям «su», поскольку большая часть среды выполнения наследуется, в многочисленных и неочевидных способы, например, контексты MAC, контексты аудита, контексты cgroup, контексты пространства имен, планирование, гранулярность таймера,…

если вы хотите полностью новый сеанс, используйте что-то вроде «логин machinectl» или «оболочка machinectl», что фактически обеспечит вашу полностью чистую, независимую, отсоединенную среду, без скрытых свойств процесса, просачивающихся из того места, куда вы вызываете его.

Сеансы входа в систему в основном связаны с концепцией сеанса аудита, и на сеансы аудита не влияет "su", фактически они определены как "закрытые", то есть таким образом, что если процесс вошел в сеанс один раз, он всегда останется с ним, как и с его дочерними элементами, то есть единственный способ получить новый сеанс - это отключить что-то от PID 1 (или что-то подобное), которое никогда не было частью сеанса.

Или, если сказать по-другому: материал, который вы вызываете через "su", будет прекрасно отображаться в "loginctl", однако, он останется частью вашего исходного сеанса, в который вы вошли изначально. Вы можете проверить это, вызвав «loginctl status» для исходного идентификатора сеанса (который вы можете увидеть через echo $ XDG_SESSION_ID)