Чому sudo -i не встановив XDG_RUNTIME_DIR для цільового користувача?

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

Я створив сервер ubuntu 16.04 для запуску системних сеансів користувачів. Тепер, намагаючись їх адмініструвати, я виявляю, що при зміні користувача через 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тайм-аута.

EDIT: Я думаю, що цей код був введений після цього обговорення . І, мабуть, su -/ sudo -iможна було б змусити працювати, але ніхто (це все ще не реалізував).

Мені, правда, цікаво, як це правильно встановити сеанс з ssh, але не з su або sudo -i?

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

Вибачте, але "su" - це інструмент для зміни особистих даних користувачів та дуже мало інших облікових даних процесів. Це не інструмент для відкриття абсолютно нового сеансу входу. Новий сеанс входу має дуже чітко встановлену, незайману настройку, не успадковує нічого від будь-якого іншого сеансу, але це дійсно не стосується змін "su" uid: більшість середовищ виконання передаються у спадок, у численних та неочевидних способи, наприклад, контексти MAC, контексти аудиту, контексти груп, контексти простору імен, планування, деталізація таймера ...

якщо ви хочете повністю новий сеанс, використовуйте щось на кшталт "machinectl логін" або "machinectl оболонка", який фактично отримає ваше повністю чисте, незалежне, від'єднане середовище, без прихованих властивостей процесу, що протікають з того місця, де ви його викликаєте в нього.

сеанси реєстрації в основному пов'язані з концепцією сеансу аудиту, а аудиторські сесії не впливають на "su", насправді вони визначаються як "запечатані", тобто таким чином, що якщо процес увійшов до сесії один раз, він завжди залишатиметься з нею, так само і з його дітьми, тобто єдиний спосіб отримати новий сеанс - це відщепити щось від PID 1 (або щось подібне), яке ніколи не було частиною сеансу.

Або сказати це по-іншому: речі, на які ви посилаєтесь через "su", виявляться просто "loginctl", однак це залишається частиною вашого початкового сеансу, ви ввійшли в систему спочатку. Ви можете перевірити це, застосувавши "статус loginctl" в ідентифікаторі оригінального сеансу (що можна побачити через echo $ XDG_SESSION_ID)