Вопрос или проблема
Если переменная окружения DISPLAY установлена и я выполняю
/bin/su - root
из пользовательской оболочки в X терминале, то входная оболочка для root настраивается, и переменная окружения DISPLAY по-прежнему присутствует.
Если я выполняю
/usr/bin/systemd-run --quiet --setenv DISPLAY -t /bin/bash -c 'echo "DISPLAY is ${DISPLAY}" ; export DISPLAY=${DISPLAY} ; DISPLAY=${DISPLAY} /bin/su - root'
[Да, наличие и export, и DISPLAY= перед командой, вероятно, избыточно.]
тогда, когда оболочка входа для root запускается, переменная окружения DISPLAY не установлена, даже несмотря на то, что она была присутствовала и была правильно выведена из процесса systemd-run перед запуском оболочки. (И я пробовал использовать –setenv DISPLAY=some_other_value, чтобы проверить, что передается другое значение.)
Проверяя усложненный
/bin/bash -c 'echo "DISPLAY is ${DISPLAY}" ; export DISPLAY=${DISPLAY} ; DISPLAY=${DISPLAY} /bin/su - root'
сам по себе, просто чтобы проверить, что запуск /bin/su -root из команды bash работает, переменная окружения отображения присутствует в оболочке входа root.
Опуская вызов bash и просто используя /bin/su с командой systemd-run, это не работает, и я включаю вызов bash из-за ответа на предыдущий вопрос
systemd-run не устанавливает переменные окружения при использовании –setenv
Почему DISPLAY не сохраняется, когда оболочка входа su запускается из systemd-run, даже если она была правильно передана в окружение systemd-run с параметром setenv?
Для справки, это на openSUSE Leap 15.6 с
systemd 254 (254.20+suse.113.gf7f6a3454e).
Ответ или решение
При выполнении команд в Linux, понимание поведения переменных окружения и утилит, таких как su и systemd-run, может быть весьма важным, особенно в контексте управления доступом и настройкой сеансов. В ситуации, описанной выше, важно разобраться, почему переменная окружения DISPLAY не сохраняется при запуске из-под systemd-run.
Давайте детально разберем особенности использования su и systemd-run в этом контексте.
Описание ситуации
Вы используете команду /bin/su - root в X-терминале, где переменная окружения DISPLAY настроена, и она правильно передаётся в новый shell. В этом случае su - создает новый логин, унаследовав окружение. Однако, при использовании systemd-run, к примеру:
/usr/bin/systemd-run --quiet --setenv DISPLAY -t /bin/bash -c 'echo "DISPLAY is ${DISPLAY}" ; export DISPLAY=${DISPLAY} ; DISPLAY=${DISPLAY} /bin/su - root'переменная DISPLAY не передается в новый shell для пользователя root, хотя была корректно настроена в окружении systemd-run.
Причины поведения
-
Изоляция окружения: система и утилита
systemd-runпредназначены для создания изолированных процессов, которые иногда используют отдельные пространства имен и не всегда унаследуют полное окружение, как это делает обычный shell. -
Баги или особенности версии systemd: Ваша версия OpenSUSE и systemd может иметь специфические особенности или баги, влияющие на передачу переменных окружения.
-
Особенности работы
su:su -инициирует новый логин shell, который обычно загружает конфигурации, такие как/etc/profile, и сбрасывает большую часть текущих переменных окружения ради имитации аутентификации прямого пользователя.
Как справиться
-
Проверка конфигураций: убедитесь, что системные конфигурационные файлы действительно включают все необходимые переменные окружения. Может иметь смысл настраивать скрипты или профили, которые явно задают необходимые переменные при запуске.
-
Изучение документации: изучите официальные документы openSUSE и systemd, чтобы выявить особенности работы конкретной версии и настройки вашей системы.
-
Использование альтернатив: Если
systemd-runне удовлетворяет вашими потребностями, возможно, другие механизмы или утилиты (например,sudoс определенными параметрами) подойдут лучше для задач управления окружением.
Заключение
Правильное управление сессиями и переменными окружения на уровне системы требует детального понимания как работы используемых утилит, так и самого окружения операционной системы. Проблемы могут быть связаны как с изоляцией процессов в systemd-run, так и с особенностями работы конкретных версий ПО. Рекомендуется тестировать различные подходы и тщательно проверять системные конфигурации для достижения наилучших результатов.