Почему 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 прямо в этого пользователя, он устанавливается правильно.

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

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

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

  • Запускать / останавливать пользовательский блок всякий раз, когда устройство монтируется / размонтируется
  • Как отключить пользовательские tmpfs / run / user / 1000, tmpfs
  • Почему люди все еще используют SFTP-тюрьмы на основе chroot SSH, а не пространства имен Systemd?
  • Что означают сообщения systemd «Проведение вакуумирования, освобождение 0 байтов»?
  • Как изменить значения по умолчанию для директив в systemd?
  • Systemd ломает usbmount
  • Загрузка Debian: прерывание цикла упорядочения (systemd)
  • Сеть Systemd: сеть IPv6 недоступна при загрузке
  • 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 - лучшая ОС в мире.