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

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

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

  • Как остановить ssh-agent при попытке всех ключей с пересылкой агента?
  • Безопасная передача пользовательского ввода в команду
  • Почему рискованно предоставлять sudo vim доступ к обычным пользователям?
  • Параметр SSH для игнорирования сценария .bashrc
  • Разрешения для файлов ACL для группы, не работающей
  • RHEL Как войти в систему как другой пользователь из оболочки?
  • Если я правильно понимаю документацию, это должно быть установлено libpam-systemd при создании сеанса пользователя. Пользовательский срез запускается правильно, так как существует каталог, в который должен указываться XDG_RUNTIME_DIR ( /run/users/$uid ). Я не решаюсь просто перекодировать его, скажем, в .bash_profile , потому что это кажется взломанным (хотя и работающим), когда pam должен заботиться об этом.

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

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

  • Согласованный и безопасный подход к учетным записям без пароля в SSH
  • Как выполнять команды в пакетном режиме по ssh?
  • Почему я могу использовать apt-get, когда я использую «su»?
  • Список журналов до начала последнего запуска
  • кэширование ключевой фразы на сервере linux
  • Файлы журналов для паники ядра в Arch Linux
  • One Solution collect form web for “Почему sudo -i не устанавливает XDG_RUNTIME_DIR для целевого пользователя?”

    Я воспроизвел эту проблему в своей системе 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 . Тем не менее, я нахожусь в середине попыток обходных решений, чтобы заставить machinectl работать, поскольку я хочу, чтобы он отвечал SELinux, поэтому возможно, что мое вождение – это то, что вызывает, например, machinectl shell для тайм-аута.

    EDIT: Я думаю, что этот код был введен после этого обсуждения . И, судя по всему, su - / sudo -i можно sudo -i работать, но никто не реализовал его (все же).

    Linux и Unix - лучшая ОС в мире.