LINUX.ORG.RU

Как создать новую сессию пользователя в logind, используя sh-скрипт?

 ,


0

1

Приветствую.

Дано: Debian v9.4 stable, Systemd, Openbox, Lightdm.

Нужно,чтобы пользователь «А» из под своей графической сессии мог запустить скрипт, который создаст от имени пользователя «Б» отдельный X-сервер и создаст в нем новую графическую сессию для пользователя «Б». То есть,

loginctl show-session $XDG_SESSION_ID
в созданной сессии должна возвратить состояние «active». Для меня оказалось новостью, что startx / xinit всего лишь создает, так сказать, workspace, но не сессию.

Уже два дня гуглю - ничего толком найти не могу - вот тут вышли из положения, но ведь там СonsoleKit, а у меня logind, затем нашел это - но чуда не произошло - не работает. В документации по loginctl и logind ничего по своему вопросу найти не смог. Тут говорят, что СonsoleKit уже не нужен, т.к. в Systemd создание сессии происходит автоматически, сразу после аутентификации в виртульном терминале либо дисплейном менеджере.
Вопросы, в таком случае, нарастают как снежный ком:

1) даже если пока что забыть за скрипт и сделать все вручную: переключаюсь на другой виртуальный терминал, логинюсь, запускаю X-сервер на этом же виртуальном терминале, то сессия ТАКИ создается корректно, но при этом СЛЕТАЮТ все сессии которые были созданы/аутентифицированы с помощью дисплейного менеджера (Lightdm в моем случае) - т.е. на них уже не переключиться - нужно по новой логиниться, контекст работы теряется - совсем нехорошо - как этого избежать? При этом сам Lightdm в множество сессий умеет: т.е, если я создам кучу сессий с помощью гритера Lightdm, то переключения между этими сессиями происходят корректно.

2) как тогда с помощью скрипта создать сессию, используя уже дисплейный менеджер, да при этом миновать этап ввода логина-пароля? В Lightdm есть консольная утилита dm-tool, но при выполнении «dm-tool switch-to-user username» все равно выкидывает в гритер. Да, все он делает верно, но мою проблему это не решает. :) Нужно процесс создания новой сессии нужного пользователя и переключения на нее сделать полностью прозрачным.


АРХАИЧНОЕ РЕШЕНИЕ
РЕШЕНИЕ ПО ПРАВИЛАМ SYSTEMD



Последнее исправление: Yaroslav_cpp (всего исправлений: 45)

Поток сознания. Читать невозможно. Перепиши кратко и понятно. Скорее всего, ты что-то делаешь не так.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Извиняюсь конечно, - редактировал ошибки, простыню под кат хотел спрятать, да не получается; даже пустые строки и пробельные символы символы убрал - глухо.

По поводу моего вопроса. Если совсем кратко, то как сделать:

xinit /usr/bin/ck-launch-session /usr/bin/wine бубубу.exe -- :1
но используя logind, а не СonsoleKit как в примере.

Yaroslav_cpp
() автор топика
Ответ на: комментарий от Yaroslav_cpp

Как вариант использовать sshpass и указать -X если графическое приложение. Наверняка есть красивый вариант, но я не знаком.

sin-ok
()

Разбей всё это на несколько задач. «Создать сессию», «проблемы со звуком» и т.д.

Вот скажем «Создать сессию». Если речь идёт о графической сессии, то я бы заскриптовал всё вокруг xinit со сменой пользователя. Или средствами дисплейного менеджера, но это наверняка придётся вручную логиниться (должен быть аналог kdmctl reserve для lightdm, он вроде умеет несколько пользователей одновременно).

Или звук. Ничего не подскажу по поводу пульса, но группа audio отвечает за доступ к микшеру als'ы (его ещё может понадобиться включить), а пульс наверняка уже монополизирует ввод альсы при запуске.

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

Укоротил ОП. Теперь должно быть более понятно, что мне нужно и что я уже пробовал. Если не затруднит, прочти пожалуйста ОП снова.

я бы заскриптовал всё вокруг xinit со сменой пользователя

Что именно? Из того что понял я в теории: startx - это фронт-энд для xinit; в Debian xinit не используется - в /etc/X11/xinit/Xinitrc сразу перенаправление на /etc/X11/Xsession, который в свою очередь инициализирует нужные переменные окружения, обрабатывает ошибки и выполняет все что лежит в /etc/X11/Xsession.d (запуск всяких ДБас, подключение ресурсов и т.д. - словом там делать нечего - уже все есть).

Теперь практика:

1) из под активной графической сессии пользователя user1 (которая находится по умолчанию на vt7) выполняю

sudo -u user2 sh -c "startx -- vt8"
- все работает и запускается от имени user2, проги работают от имени user2. Переключение между терминалами user1-user2 работает. Ляпота. Вот только сессии у этого нового X-сервера user2 нет:
loginctl show-session $XDG_SESSION_ID
возвращает ерунду а XDG_SESSION_ID пустая. Миссия провалена; и ведь не поспоришь: logind создает сессию после аутентификации либо в вирт. терминале, либо в дисплейном менеджере, а тут никакой аутентификации user2 не было; ведь user1 в sudoers имеет право выполнять от имени user2 все что угодно - сделано для достижения той самой прозрачности процесса; и что теперь делать?

2) ежели создать кучу сессий с разными пользователями из под граф. гритера Lightdm и попробовать попереключаться между ними - все работает, если в каждой такой сессии повызывать

loginctl show-session $XDG_SESSION_ID
- все ок - сессия активна, переменная $XDG_SESSION_ID не пустая. Миссия выполнена. Что же такого секретного делает Lightdm при создании сессии? (а ничего, просто logind отработал, ведь тут процесс аутентификации имел место быть) Как это повторить самому но в скрипте из под уже активной графической сессии и чтобы все прозрачно было?

3) вручную логинюсь на третьем виртуальном терминале, пишу

startx -- vt3
Ииииии все хорошо, запускается OpenBox, все работает,
loginctl show-session $XDG_SESSION_ID
тоже возвращает значение активной сессии. Хорошо! Таким же способом создаю еще парочку разных сессий на других терминалах - переключаюсь между ними - работает. Замечательно! Миссия выполнена. (и снова бинго, аутентификация в вирт терминале-то была) Как это повторить самому но в скрипте из под уже активной графической сессии?

Вот в итоге и получается: либо нужно уметь эмулировать аутентификацию на терминале / граф. гритере, либо нужно знать способы воздействия на systemd / logind - чтобы заставить его создать сессию. За этим я сюда на форум и пришел. В ConsoleKit это делалось элементарным вызовом ck-launch-session, а тут ХЗ.

Yaroslav_cpp
() автор топика
Ответ на: комментарий от sin-ok

Почитал про sshpass. Много крику, что небезопасно, но от безысходности чего только не сделаешь. Буду пробовать. О такой программе не знал, спасибо за отзыв.

Yaroslav_cpp
() автор топика
Ответ на: комментарий от Yaroslav_cpp

Что же такого секретного делает Lightdm при создании сессии? (а ничего, просто logind отработал, ведь тут процесс аутентификации имел место быть) Как это повторить самому но в скрипте из под уже активной графической сессии и чтобы все прозрачно было?

А вот хз. Я не фанат logind и стараюсь избавится от него когда это только можно, так что тут не помогу. Но по крайней мере здесь понятно, куда копать. И ещё мне не понятно, если проги работают, vt с иксами переключаются, то зачем нужен факт регистрации сессии в logind.

Ииииии все хорошо, запускается OpenBox, все работает

Не уверен, но предположу что в этом случае startx не напрямую запускает окружение, а отдаёт команду какой то другой запускалке, которая всё и делает. Для xfce это startxfce, и я точно знаю что в kde5 есть какой то startkde или типа того. Возможно logind работает через dbus и будет проще воспользоваться этой самой запускалкой openbox'а для регистрации сессии.

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

И ещё мне не понятно, если проги работают, vt с иксами переключаются, то зачем нужен факт регистрации сессии в logind.

Это сейчас все хорошо. Откуда мне знать что будет завтра? Точно есть необходимость запуска софта от постороннего пользователя как в собственной Х-сессии так и в посторонней, которая будет создаваться без лишнего шума по скрипту. Неизвестно какой софт (в том числе и под вайном) захотят использовать или какого рода разработкой займутся люди. Софт может потребовать активной сессии для предоставления монопольного доступа к чему либо, либо при отладке. Пока что таким софтом является пульса - доступ к звуковому устройству даем только пользователю с активной сессией; в группе audio всего один пользователь - это сама пульса и больше никто, членство пользователей в группе audio было отброшено как раз по причине вечного монопольного доступа к звуковому устройству: user1 может прослушать микрофон user2 и наоборот независимо от состояния сессии, например. Может и паранойя, но мне это не нравится.

Возможно logind работает через dbus и будет проще воспользоваться этой самой запускалкой openbox'а для регистрации сессии.

Ага, гугление продолжается.

Yaroslav_cpp
() автор топика
Ответ на: комментарий от Yaroslav_cpp

В догонку исправлю неточность, вот это:

sudo -u user2 sh -c "startx -- vt8"
просто так не сработает. Команда просто уйдет в фоновое выполнение и перейдет на vt8 только после многократного нажатия ctrl+c. В выхлопе будут ошибки на заблокированный .Xauthority. Путь к нему нужно явно указывать.

Вот это уже работает корректно:

sudo -u user2 sh -c "env XAUTHORITY=/home/user2/.Xauthority ERRFILE=/home/user2/.xsession-errors startx -- vt8"

Yaroslav_cpp
() автор топика
Ответ на: комментарий от Yaroslav_cpp

Ну, аргументов я не понял. Сессия logind не сделает всю систему стабильней потому что это ещё одна прослойка, которая так же может создать проблему (например в силу какого то обновления политик безопастности или изменения спецификации). И всё равно придётся залезть руками и разобраться кто и где упал.

А монопольный доступ и прочее... Не проще тогда уже перейти на виртуальные машины? Если грамотно подобрать окружение, да ещё железо хорошее, а задачи не слишком мультимедийные, то оверхед будет не глобальным. Наверное.

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

Из того материала, что был найден в сети, становится ясно, что никакого удобного метода типа «systemd --user --create-new-session» не предусмотрено, во всяком случае пока.

Раз все крутится вокруг процесса аутентификации пользователя, вот как мы поступим:

1) создадим юнит автовхода через getty для пользователя «Б» на выбранном виртуальном терминале (как это делается в systemd) и переведем его в состояние disable, т.к. его запуск нужен только по требованию;

2) команды для запуска/останова юнита добавим в sudoers с меткой NOPASSWD (чтобы ОС не просила у пользователя «А» пароль при работе с юнитом);

3) тот самый скрипт:

sudo systemctl start getty@tty8.service
#дадим время на создание сеанса
sleep 1
user_session_data=`loginctl list-sessions | grep имя_пользователя_Б`
user_session_id=`echo $user_session_data | cut -d " " -f 1`
user_uid=`echo $user_session_data | cut -d " " -f 2`

if [[ -n $user_session_data ]] && [[ $(ls /run/user | grep $user_uid) = $user_uid ]]
then

	sudo -H -u имя_пользователя_Б bash -c "env XDG_SESSION_ID=$user_session_id XAUTHORITY=/home/имя_пользователя_Б/.Xauthority ERRFILE=/home/имя_пользователя_Б/.xsession-error startx путь_к_программе_которую_хотим_запустить -- vt8"

else

	echo "Сеанс для пользователя Б все еще не существует."

fi

sudo systemctl stop getty@tty8.service


Ну, аргументов я не понял.

Тут все просто: есть черный ящик (ОС Дебиан с системд) и есть требование его обслуживать, при этом ничего, радикально, не меняя.

Не проще тогда уже перейти на виртуальные машины?

Возможно. Пока гуглил, нашел вот это. Там как раз человек обьяснил что, программы типа sudo, su и пр., не предназначены для создания новых сессий и тоже посоветовал вирт. машины, только made in systemd.

Yaroslav_cpp
() автор топика
Ответ на: комментарий от Yaroslav_cpp

Ты пытаешься решить современные задачи инструментами из прошлого десятилетия.

sudo ненужно, используй polkit для разрешения прав на запуск сервиса.
https://wiki.archlinux.org/index.php/Polkit_(Русский)#Allow_management_of_ind...

автологин в консоль и последующие костыли ненужны, делай запуск иксов с нужным пользователем и софтом средствами systemd
RFC HOWTO: автологин в иксовую сессию с помощью systemd

bass ★★★★★
()
Последнее исправление: bass (всего исправлений: 1)
Ответ на: комментарий от bass

автологин в консоль

Да, автологин в консоль это плохо.

Ты пытаешься решить современные задачи инструментами из прошлого десятилетия.
sudo ненужно, используй polkit

А вот это фанатизм. sudo в любом случае нужно, а инструмент это инструмент. Молотку не нужен лазерный прицел и ядерный реактор.

kirill_rrr ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.