Bug 44604

Summary: Интерфейс «org.freedesktop.Secret.Collection» для пути /org/freedesktop/secrets/collection/login объекта не найден
Product: Sisyphus Reporter: Evgeny Shesteperov <alimektor>
Component: kf5-kwalletAssignee: Slava Aseev <ptrnine>
Status: ASSIGNED --- QA Contact: qa-sisyphus
Severity: normal    
Priority: P5 CC: aris, shrek, varaksaaa, zerg
Version: unstable   
Hardware: x86_64   
OS: Linux   

Description Evgeny Shesteperov 2022-12-13 13:43:06 MSK
Версия
======

kf5-kwallet-5.100.0-alt1
kde5-kwalletmanager-22.08.3-alt1
evolution-3.46.2-alt1

Дистрибутивы
============

- p10-kworkstation-10.1-x86-64

Шаги воспроизведения
====================

1. Установить evolution:
   
		# apt-get install -y evolution

2. Очистить конфигурацию KWallet:
   
		$ rm -f ~/.local/share/kwalletd/*

3. Запустить evolution и настроить почту, например, Yandex.
4. Ввести пароль от почты.
5. Ввести пароль от кошелька (в окне Служба бумажника KDE → Finish, ввести пароль два раза → OK)
6. Ввести повторно пароль от почты (с отмеченным чекбоксом Добавить этот пароль к связке ключей) → OK.
7. Проверить, что всё настроено правильно закрытием, открытием Evolution, то есть пароль не спрашивается ни от почты, ни от Бумажника.
8. Открыть Управление бумажниками:
   
		$ kwalletmanager5

9. Выбрать Настройка → Настроить бумажник → Контроль доступа.
10. Включить параметр "Запрашивать подтверждение при обращении приложений к бумажнику".
11. Нажать "ОК", ввести пароль пользователя → OK.
12. Перезагрузить систему.
13. Запустить Evolution:
    
		$ evolution

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

Фактический результат: запрашивает пароль от почты. Если ввести пароль от почты, будет повторный запрос пароля от почты и так далее. При этом если ввести пароль

Каждый ввод пароля сопровождается выводом в терминал:

	(evolution:4550): e-data-server-ui-WARNING **: 13:05:23.277: credentials_prompter_store_credentials_cb: Failed to store source credentials: Интерфейс «org.freedesktop.Secret.Collection» для пути /org/freedesktop/secrets/collection/login объекта не найден
Comment 1 Slava Aseev 2022-12-19 18:11:48 MSK
Проблема, похоже, возникает из-за того, что кто-то начал запускать gnome-keyring, даже когда kwalletd уже запущен. Если прибить gnome-keyring, все начинает работать как надо.

Можно попробовать починить добавлением DBus Service файла.

Вообще, service файл для org.freedesktop.secrets для kwallet уже был, но я его не приложил после прохождения Secret Service в апстрим, т.к. все работало из без него. В любом случае этот service файл мало поможет. Чтобы надежно избежать конфликтов kwalletd/gnome-keyring нам нужен какой-то явный механизм переключения бэкендов.
Comment 2 Slava Aseev 2022-12-19 21:09:09 MSK
(Ответ для Slava Aseev на комментарий #1)
> Можно попробовать починить добавлением DBus Service файла.

Неа, проверил, это не помогает. Тут вообще запускаются сразу два org.freedesktop.secrets сервиса.
К тому же, баг https://bugzilla.altlinux.org/42507 воспроизводится и на старой версии, где у kwallet'а еще был dbus-service файл (но там активируется только один сервис, а именно gnome-keyring).

В общем, нужно либо решать проблему конфликтом gnome-keyring/kwalletd, либо:
> Чтобы надежно избежать конфликтов kwalletd/gnome-keyring нам нужен какой-то
> явный механизм переключения бэкендов.

Как я понял, в dbus-daemon все активируемые сервисы хранятся в хэш-таблице, где в качестве ключа используется название сервиса (например, org.freedesktop.secrets).
Соответственно, никаких дублей там быть не может, а порядок попадания сервисов в эту таблицу нигде не регламентирован (разве что самим кодом). Надо посмотреть, возможно получится сделать так, чтобы перед записью данных в эту хэш-таблицу все service-конфиги сортировались по дате изменения. В таком случае, мы сможем явно задавать сервис-конфиг, в котором указанный там исполняемый файл возымеет приоритет при dbus-активации (и можно будет приделать какую-нибудь настройку/control для этого).
Comment 3 Sergey V Turchin 2022-12-20 11:17:11 MSK
(In reply to Slava Aseev from comment #1)
> Проблема, похоже, возникает из-за того, что кто-то начал запускать
> gnome-keyring, даже когда kwalletd уже запущен. Если прибить gnome-keyring,
> все начинает работать как надо.
> 
> Можно попробовать починить добавлением DBus Service файла.
Значит, всё-таки зря его убрали.
Comment 4 Sergey V Turchin 2022-12-20 11:19:05 MSK
Когда был service-файл KDE-шный, вроде проблемы не было, значит порядок запуска был подходящий. Надо вернуть файл, а потом, если будет проблема, уже думать над порядком.
Comment 5 Slava Aseev 2022-12-20 12:33:50 MSK
(Ответ для Sergey V Turchin на комментарий #4)
> Когда был service-файл KDE-шный, вроде проблемы не было, значит порядок
> запуска был подходящий. Надо вернуть файл, а потом, если будет проблема, уже
> думать над порядком.

Попробовал с файлом - разницы нет. Запускаются сразу и gnome-keyring и kwalletd при логине. gnome-keyring запускает xdg-desktop-portal.service. Если остановить gnome-keyring-daemon, и перезапустить xdg-desktop-portal.service, gnome-keyring-daemon снова запускается/активируется. Причем это происходит даже если service-файл для kwalletd на месте.
Comment 6 Slava Aseev 2022-12-20 13:04:14 MSK
(Ответ для Slava Aseev на комментарий #5)
> Попробовал с файлом - разницы нет. Запускаются сразу и gnome-keyring и
> kwalletd при логине. gnome-keyring запускает xdg-desktop-portal.service.
> Если остановить gnome-keyring-daemon, и перезапустить
> xdg-desktop-portal.service, gnome-keyring-daemon снова
> запускается/активируется. Причем это происходит даже если service-файл для
> kwalletd на месте.

Хотя, если перезапустить уже kwalletd, а потом повторить всю процедуру, gnome-keyring не будет запускаться. Видимо, при входе в систему получается гонка, что-то вроде такого:
- Запускается kwalletd
- Запускается gnome-keyring (т.к. org.freedesktop.secrets еще нету на шине)
- gnome-keyring регистрирует org.freedesktop.secrets
- kwalletd пытается тоже, но уже не может, и при этом продолжает работать
Comment 7 Slava Aseev 2022-12-20 14:17:53 MSK
Кстати, если создать org.freedesktop.secrets.service для kwalletd в /usr/local/share/dbus-1/services, то он возымеет приоритет над gnome-keyring. Похоже, это потому что в XDG_DATA_DIRS /usr/local/share стоит перед /usr/share. /usr/share/kf5 тоже, но с ним это не работает, почему-то.
Comment 8 Sergey V Turchin 2022-12-20 15:03:47 MSK
(In reply to Slava Aseev from comment #7)
> /usr/local/share/dbus-1/services
Низя туда.

(In reply to Slava Aseev from comment #7)
> Похоже, это потому что в XDG_DATA_DIRS /usr/local/share стоит
> перед /usr/share. /usr/share/kf5 тоже, но с ним это не работает, почему-то.
Скорее, потому, что
<standard_session_servicedirs />
обрабатывается до
<includedir>/etc/dbus-1/session.d</includedir>
Comment 9 Slava Aseev 2022-12-20 17:28:36 MSK
(Ответ для Sergey V Turchin на комментарий #8)
> (In reply to Slava Aseev from comment #7)
> > /usr/local/share/dbus-1/services
> Низя туда.
Да оно понятно, это я для примера. Проблема там в том, что dbus запускается раньше того, как startplasma прокинет переменную XDG_DATA_DIRS, поэтому /usr/share/kf5 там не оказывается. Прокинуть ее туда потом не представляется возможным, только если перезапустить dbus.service (и после перезапуска начинает активироваться kwalletd вместо gnome-keyring)

> Скорее, потому, что
> <standard_session_servicedirs />
> обрабатывается до
> <includedir>/etc/dbus-1/session.d</includedir>

Попробовал поднять строку с <includedir>/etc/dbus-1/session.d</includedir> наверх и у меня заработало, активироваться стал kwalletd.
Comment 10 Sergey V Turchin 2022-12-21 10:29:32 MSK
(In reply to Slava Aseev from comment #9)
> Попробовал поднять строку с <includedir>/etc/dbus-1/session.d</includedir>


> наверх и у меня заработало, активироваться стал kwalletd.
Это понятно, но, скорее всего, неправильно.
Может, у мантейнера dbus есть мысль на этот счёт?

Я бы поменял порядок. Сейчас поломки со стороны мантейнера стала небольшой. Да и тестирвоание работает.

P.S.
Добавлять в dbus возможность обновить переменные смысла не вижу, т.к. после этого придется его перезапускать по сути. Если нет проблем, чтобы он сам перезапустился после такого, то может и так лучше.
Comment 11 Slava Aseev 2022-12-21 12:16:02 MSK
(Ответ для Sergey V Turchin на комментарий #10)
> P.S.
> Добавлять в dbus возможность обновить переменные смысла не вижу, т.к. после
> этого придется его перезапускать по сути. Если нет проблем, чтобы он сам
> перезапустился после такого, то может и так лучше.

Перезапускать может и не придется, т.к. у dbus есть метод ReloadConfig(), его можно вызвать после задания /usr/share/kf5 в startplasma. Проблема в том, что к моменту, когда это будет вызвано, gnome-keyring уже может быть запущен. Ну и также в том, что сейчас нет никакой возможности прокинуть переменную окружения в сам dbus.
Comment 12 Slava Aseev 2022-12-21 12:20:22 MSK
(Ответ для Sergey V Turchin на комментарий #10)
> Я бы поменял порядок. Сейчас поломки со стороны мантейнера стала небольшой.
> Да и тестирвоание работает.

Может добавить /usr/share/kf5/dbus-1/session.d для KDE? И впихнуть его как раз в самое начало, ну и перенести туда kf5.conf
Comment 13 Valery Inozemtsev 2022-12-21 12:42:12 MSK
пока есть /usr/share/dbus-1/services/org.freedesktop.secrets.service врятли kwalletd5 можно бедет запустить раньше gnome-keyring-daemon
Comment 14 Sergey V Turchin 2022-12-21 16:18:45 MSK
(In reply to Valery Inozemtsev from comment #13)
> пока есть /usr/share/dbus-1/services/org.freedesktop.secrets.service врятли
> kwalletd5 можно бедет запустить раньше gnome-keyring-daemon
Можно без проблем, как выше обсуждалось. И без изменений в gnome-keyring.
Comment 15 Sergey V Turchin 2022-12-21 16:24:50 MSK
(In reply to Slava Aseev from comment #12)
> Может добавить /usr/share/kf5/dbus-1/session.d для KDE?
В момент запуска пользовательского dbus ещё не дополнен XDG_DATA_DIRS KDE-шным каталогом. А так бы я давно это сделал.

Надо посмотреть, как оно с systemd, а то уже всё готово для автозапуска пользовательской сессии через systemd.
Comment 16 Slava Aseev 2022-12-22 20:56:45 MSK
Попробовал сделать рестарт dbus в startplasma сразу после того, как в systemd1 пробросятся переменные и ему пошлется Reload: https://git.altlinux.org/people/ptrnine/packages/?p=plasma5-workspace.git;a=commit;h=5b8493055fbe785400f22ba182eeb30ffaa00256

В итоге все начинает работать как надо, gnome-keyring больше не запускается.
По /proc/PID/environ у dbus-daemon видно, что XDG_DATA_DIRS до него долетел.
Так что остается только включить systemd boot в плазме по-умолчанию, и можно будет отправлять.

Т.е. zerg таки был прав, больше ничего делать не надо, gnome-keyring после этих действий уже не будет запускаться (я до этого, оказывается, просто впихнул рестарт dbus'а не в то место).
Comment 17 Artem Varaksa 2023-12-21 15:04:58 MSK
Воспроизводится на виртуальной машине:

[sisyphus] kworkstation-10.2.1-x86-64
evolution-3.50.2-alt1.x86_64
kf5-kwallet-5.113.0-alt1.x86_64
kde5-kwalletmanager-23.08.4-alt1.x86_64
pam0_kwallet5-5.27.10-alt1.x86_64

Не воспроизводится на виртуальной машине:

[p10] kworkstation-10.2.1-x86-64
evolution-3.44.0-alt1.x86_64
kf5-kwallet-5.112.0-alt2.x86_64
kde5-kwalletmanager-23.04.3-alt1.x86_64
pam0_kwallet5-5.27.9-alt1.x86_64

При этом:

* Если открывать evolution в sisyphus несколько раз, уже на шаге 7 воспроизводится повторный запрос пароля почты. А на шаге 5 создаётся новый кошелёк, даже если не удалять "kdewallet" (т.е. не делать шаг 2).

* В p10 в kwalletmanager5 только "kdewallet", в sisyphus - список из "kdewallet" и "Связка ключей по умолчанию", причём пароль от почты сохраняется именно в "Связка ключей по умолчанию", а не в "kdewallet", как в p10.

* "Запрашивать подтверждение при обращении приложений к бумажнику" не требует пароль бумажника в p10, просто просит разрешить или запретить доступ. В sisyphus запрашивается пароль бумажника, а затем уже начинает запрашивать пароль от почты много раз.