su -l не работает, loginctl показывает другого пользователя

Вопрос или проблема

Я хочу переключиться на другого пользователя, но loginctl показывает, что сессия предыдущего пользователя используется

Я начинаю как пользователь ubuntu.

$ loginctl session-status | head -n1
2 - ubuntu (1000)
sudo su -l newuser # Я даже использовал флаг --login! Который должен ВПИСАТЬСЯ!
$ loginctl session-status | head -n1
2 - ubuntu (1000)

Это влияет на такие вещи, как lingering.

Как я могу переключиться на другого пользователя (без пароля), так чтобы loginctl понимал это?

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

Этот ответ не полный. Он показывает, почему su -l не работает, но не предоставляет решения, кроме ссылок на systemd-run или machinectl в руководстве.

Цитата из руководства su:

   -, -l, --login
       Запуск оболочки как регистрационной оболочки с окружающей средой, аналогичной
       настоящему входу.

       Обратите внимание, что на системах, основанных на systemd, новая сессия может
       быть определена как настоящая точка входа в систему. Однако, su не создает
       настоящую сессию (по PAM) с этой точки зрения. Вам нужно использовать инструменты
       такие как systemd-run или machinectl для инициации полной, настоящей сессии.

Ответ или решение

Для решения проблемы с использованием команды su -l, которая не меняет зарегистрированную сессию на уровне loginctl, важно понять, как работает механизм аутентификации и сессий в системах на базе systemd. Рассмотрим теоретическую часть, пример и конкретное приложение в вашей ситуации.

Теоретическая часть

Команда su (от слов substitute user) используется для смены пользователя в текущей сессии терминала. Она имитирует переход на другого пользователя, однако не создает новую сессию, зарегистрированную системой управления сессиями и аутентификации PAM (Pluggable Authentication Modules).

Systemd, ставший стандартом управления сессиями и службами в современных системах GNU/Linux, ведет учет сессий и пользователей через компоненты вроде loginctl. Инструменты вроде su не взаимодействуют напрямую с systemd для создания новых сессий, и поэтому не учитываются в loginctl как новые или отдельные сессии. Для полноценного создания сессии systemd рекомендует использовать команды systemd-run или machinectl.

Пример

Рассмотрим применение команды su -l:

  1. Вы входите в систему как пользователь ubuntu.
  2. Вы запускаете su -l newuser, предполагая, что смените контекст на нового пользователя newuser.

Такой подход, даже с пометкой --login, меняет только оболочку и окружение пользователя, но не создает новую сессию systemd. Поэтому сессия остается зарегистрированной за пользователем ubuntu в выводе loginctl.

Применение на практике

Для корректной смены сессии, чтобы она была видна для loginctl, и имитации настоящего входа пользователя в систему, можно использовать команду systemd-run. Ниже описан процесс.

Использование systemd-run

systemd-run позволяет запустить процесс с новыми системными параметрами и может создавать полноценную сессию:

sudo systemd-run --user --tty --describe="Отладка как newuser" --setenv=USER=newuser /bin/bash

Эта команда создаст новую систему в environment переменных, а также полномочия, аналогичные реальному входу, с корректной регистрацией в системе systemd и loginctl. Вам потребуется ввести пароль по умолчанию, поэтому убедитесь, что у вас есть соответствующие разрешения.

Плюсы такого подхода

  1. Чистота сессий: Каждая новая сессия корректно отслеживается systemd, что позволяет использовать параметры вроде linger и другие специфические для пользователя настройки.
  2. Соответствие окружению: Вы точно имитируете окружение работы приложения или службы, выполняющегося под newuser, минимизируя возможности нарушения окружения из-за сессий.
  3. Меньшие риски ошибок: Воспользовавшись полной сессией, вы уменьшаете вероятность несоответствий поведения приложения или процесса, вызванных разными сессиями.

Альтернативы

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

Заключение

Понимание того, как работают сессии в контексте systemd, является ключом к возможности их корректной смены и управления процессами. Используя systemd-run, вы создаете полноценную сессию пользователя, минимизируя риски неправильной настройки или тестирования окружения. Таким образом, вы имеете возможность точно отладить свое приложение или сервис в соответствующих условиях без ошибок, связанных с системой управления сессиями.

Оцените материал
Добавить комментарий

Капча загружается...