Bug 38229 - Невозможно сменить пользователя, если у пользователя настроен автоматический вход и пустой пароль
Summary: Невозможно сменить пользователя, если у пользователя настроен автоматический ...
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: plymouth (show other bugs)
Version: unstable
Hardware: x86_64 Linux
: P5 normal
Assignee: Олег Соловьев
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks: 33000
  Show dependency tree
 
Reported: 2020-03-17 14:55 MSK by Антон Мидюков
Modified: 2020-03-31 18:29 MSK (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Антон Мидюков 2020-03-17 14:55:04 MSK
Невозможно сменить пользователя, если у пользователя настроен автоматический вход и пустой пароль. Это актуально для live, где пользователь altlinux имеет пустой пароль и настроен автовход. Проявляется как у lightdm-gtk-greeter, так и у slick-greeter.
Comment 1 manowar@altlinux.org 2020-03-17 15:04:16 MSK
А что проявляется-то? Прошу по-порядку...
Comment 2 Антон Мидюков 2020-03-17 15:19:20 MSK
(Ответ для manowar@altlinux.org на комментарий #1)
> А что проявляется-то? Прошу по-порядку...

Загружаемся в live. Нажимаем завершить сеанс или сменить пользователя, сеанс завершается и тут же происходит автовход.
Создаём ещё одного пользователя. Завершаем сеанс, происходит автовход в сеанс пользователя altlinux.
Задаём пароль пользователю altlinux, и только тогда можно завершить сеанс и авторизоваться под другим пользователем.
Comment 3 manowar@altlinux.org 2020-03-17 15:29:57 MSK
Т.е. принудительное завершение сеанса не должно приводить к автоматическому воходу в систему? Вероятно вы правы. Вопрос в том, можно ли это как-то отследить...
Comment 4 Антон Мидюков 2020-03-17 15:51:41 MSK
(Ответ для manowar@altlinux.org на комментарий #3)
> Т.е. принудительное завершение сеанса не должно приводить к автоматическому
> воходу в систему? Вероятно вы правы. Вопрос в том, можно ли это как-то
> отследить...

В предыдущем релизе lightdm такой проблемы не было. Как понять принудительное? Самое обычное завершение сеанса пользователем, после которого не дожен происходить автоматический вход в этот сеанс. Во всяком случае без временной выдержки, которая должна включаться отдельно, опционально.
Comment 5 Антон Мидюков 2020-03-18 13:55:30 MSK
Дело не в lightdm. Висит в запущенном состоянии plymouth-start.service, чего быть не должно. Если его остановить, то выход из сессии происходит успешно.

Перевешиваю на plymouth. Со вчерашнего дня пытаюсь понять странности с запуском lightdm, gdm, sddm. Похоже, после обновления systemd до 245 plymouth-start.service перестал завершаться после выполнения plymouth-quit.service
Т.е. plymouth таки завершается, но начинается тут же заново.
Наверное, теперь для systemd завершение программы (не аварийное) есть повод для запуска её вновь. И нужно как-то по-другому останавливать plymouth. Или в plymouth-start.service нужно что-то менять. Может сделать его:
Type=oneshot
?
Comment 6 Alexey Shabalin 2020-03-18 14:59:00 MSK
(Ответ для Антон Мидюков на комментарий #5)
> Дело не в lightdm. Висит в запущенном состоянии plymouth-start.service, чего
> быть не должно. Если его остановить, то выход из сессии происходит успешно.



> 
> Перевешиваю на plymouth. Со вчерашнего дня пытаюсь понять странности с
> запуском lightdm, gdm, sddm. Похоже, после обновления systemd до 245
> plymouth-start.service перестал завершаться после выполнения
> plymouth-quit.service
> Т.е. plymouth таки завершается, но начинается тут же заново.
> Наверное, теперь для systemd завершение программы (не аварийное) есть повод
> для запуска её вновь. И нужно как-то по-другому останавливать plymouth. Или
> в plymouth-start.service нужно что-то менять. Может сделать его:
> Type=oneshot
> ?
Comment 7 Alexey Shabalin 2020-03-18 15:02:59 MSK
(Ответ для Антон Мидюков на комментарий #5)
> Дело не в lightdm. Висит в запущенном состоянии plymouth-start.service, чего
> быть не должно. Если его остановить, то выход из сессии происходит успешно.

У нас plymouth стартует из initrd, поэтому plymouth-start.service вообще не должен стартовать. Должен только plymouth-quit.service отработать.
plymouth-start.service - это сервис для initrd, если бы в initrd был systemd.

> 
> Перевешиваю на plymouth. Со вчерашнего дня пытаюсь понять странности с
> запуском lightdm, gdm, sddm. Похоже, после обновления systemd до 245
> plymouth-start.service перестал завершаться после выполнения
> plymouth-quit.service
> Т.е. plymouth таки завершается, но начинается тут же заново.
> Наверное, теперь для systemd завершение программы (не аварийное) есть повод
> для запуска её вновь. И нужно как-то по-другому останавливать plymouth. Или
> в plymouth-start.service нужно что-то менять. Может сделать его:
> Type=oneshot
> ?

oneshot нельзя, потому что там демон остается работать. oneshot только для одноразовых скриптов.
Comment 8 Антон Мидюков 2020-03-18 16:38:13 MSK
(Ответ для Alexey Shabalin на комментарий #7)
> oneshot нельзя, потому что там демон остается работать. oneshot только для
> одноразовых скриптов.

Его plymouth-quit.service завершает в таком случае.

>У нас plymouth стартует из initrd, поэтому plymouth-start.service вообще не >должен стартовать. Должен только plymouth-quit.service отработать.
>plymouth-start.service - это сервис для initrd, если бы в initrd был systemd.

Посмотрел сборку от 27.02.2020. Запускался таки plymouth-start.service, на 15 мс.
Comment 9 Антон Мидюков 2020-03-24 19:22:40 MSK
(Ответ для Alexey Shabalin на комментарий #7)
> (Ответ для Антон Мидюков на комментарий #5)
> > Дело не в lightdm. Висит в запущенном состоянии plymouth-start.service, чего
> > быть не должно. Если его остановить, то выход из сессии происходит успешно.
> 
> У нас plymouth стартует из initrd, поэтому plymouth-start.service вообще не
> должен стартовать. Должен только plymouth-quit.service отработать.
> plymouth-start.service - это сервис для initrd, если бы в initrd был systemd.


Я удалил plymouth-start.service со всеми ссылками на него, собралось:
[#248433] TESTED plymouth.git=0.9.4-alt3

Помогло. Как такой вариант?
Comment 10 Alexey Shabalin 2020-03-25 20:03:56 MSK
(Ответ для Антон Мидюков на комментарий #9)
> (Ответ для Alexey Shabalin на комментарий #7)
> > (Ответ для Антон Мидюков на комментарий #5)
> > > Дело не в lightdm. Висит в запущенном состоянии plymouth-start.service, чего
> > > быть не должно. Если его остановить, то выход из сессии происходит успешно.
> > 
> > У нас plymouth стартует из initrd, поэтому plymouth-start.service вообще не
> > должен стартовать. Должен только plymouth-quit.service отработать.
> > plymouth-start.service - это сервис для initrd, если бы в initrd был systemd.
> 
> 
> Я удалил plymouth-start.service со всеми ссылками на него, собралось:
> [#248433] TESTED plymouth.git=0.9.4-alt3
> 
> Помогло. Как такой вариант?

Мне не очень нравится такое решение.
на plymouth-start.service есть зависимости не только в пакете plymouth, но и в systemd, gdm.

Надо попробовать 3 таких варианта:
- просто замаскировать systemctl mask plymouth-start.service
- добавить в plymouth-start.service ConditionPathExists=/etc/initrd-release, тогда вне initrd он стартовать не должен. Но как к этому отнесутся другие зависимые сервисы непонятно.
- заменить в plymouth-start.service ExecStart=/bin/true
Comment 11 Антон Мидюков 2020-03-26 19:03:35 MSK
(Ответ для Alexey Shabalin на комментарий #10)
> 
> Мне не очень нравится такое решение.
> на plymouth-start.service есть зависимости не только в пакете plymouth, но и
> в systemd, gdm.

А почему сборочница это пропустила?

> 
> Надо попробовать 3 таких варианта:
> - просто замаскировать systemctl mask plymouth-start.service

Этот вариант проверил. Работает. Проблем не заметил. Может на этом варианте и остановимся?

> - добавить в plymouth-start.service ConditionPathExists=/etc/initrd-release,
> тогда вне initrd он стартовать не должен. Но как к этому отнесутся другие
> зависимые сервисы непонятно.
> - заменить в plymouth-start.service ExecStart=/bin/true
Comment 12 Антон Мидюков 2020-03-28 05:40:11 MSK
(Ответ для Антон Мидюков на комментарий #11)
> (Ответ для Alexey Shabalin на комментарий #10)
> > 
> > Мне не очень нравится такое решение.
> > на plymouth-start.service есть зависимости не только в пакете plymouth, но и
> > в systemd, gdm.
> 
> А почему сборочница это пропустила?
> 
> > 
> > Надо попробовать 3 таких варианта:
> > - просто замаскировать systemctl mask plymouth-start.service
> 
> Этот вариант проверил. Работает. Проблем не заметил. Может на этом варианте
> и остановимся?

При использовании шифрованного раздела не получается загрузиться:
https://lists.altlinux.org/pipermail/sisyphus/2020-March/368499.html

Ситуацию воспроизвёл. Так что не подходит этот вариант. splash не получается прервать, запускается снова.

> > - добавить в plymouth-start.service ConditionPathExists=/etc/initrd-release,
> > тогда вне initrd он стартовать не должен. Но как к этому отнесутся другие
> > зависимые сервисы непонятно.
> > - заменить в plymouth-start.service ExecStart=/bin/true

В обоих вариантах при использовании шифрованного раздела splash не прерывается на ввод пароля. Приходится нажимать ESC, чтобы ввести пароль. Затем, если нажать ESC, splash показывается снова и работает до своего завершения. Является ли это регрессом, напишу позже, не проверил.
Comment 13 Антон Мидюков 2020-03-28 14:17:16 MSK
(Ответ для Антон Мидюков на комментарий #12)
> (Ответ для Антон Мидюков на комментарий #11)
> > (Ответ для Alexey Shabalin на комментарий #10)
> > > - добавить в plymouth-start.service ConditionPathExists=/etc/initrd-release,
> > > тогда вне initrd он стартовать не должен. Но как к этому отнесутся другие
> > > зависимые сервисы непонятно.
> > > - заменить в plymouth-start.service ExecStart=/bin/true
> 
> В обоих вариантах при использовании шифрованного раздела splash не
> прерывается на ввод пароля. Приходится нажимать ESC, чтобы ввести пароль.
> Затем, если нажать ESC, splash показывается снова и работает до своего
> завершения. Является ли это регрессом, напишу позже, не проверил.

Проверил, не регресс.
Comment 14 Repository Robot 2020-03-31 18:29:20 MSK
plymouth-1:0.9.4-alt3 -> sisyphus:

 Tue Mar 31 2020 Anton Midyukov <antohami@altlinux> 1:0.9.4-alt3
 - plymouth-start.service: ExecStart=/bin/true (Closes: 38229)