Может всё-таки на systemd ?
Проблема-то как раз в нём, что он корректно не даёт отработать pam_mount.
THIS IS A BUG OF THE CALLER. systemd в данном случае не является вызывающей стороной, всё дело в настройке PAM-стека. Посмотрел код:
assert_root() определяется и вызывается только в
pam_mount.c, в двух местах:
pam_sm_open_session() и
pam_sm_close_session(). Лог сокращён, поэтому непонятно. Но по идее в первом месте никак не должно. А со вторым интереснее:
ret = HX_init();
if (ret <= 0)
l0g("libHX init failed: %s\n", strerror(errno));
ret = PAM_SUCCESS;
w4rn("received order to close things\n");
assert_root();
То бишь после успешной инициализации
libHX и предупреждения может вылазить при неверной настройке PAM-стека (параметр
debug можно добавить в стек). Эту пару функций открытия/закрытия сессии должен вызывать менеджер сеансов, работающий с привилегиями root. Интересная библиотека:
apt-cache show libHX и удивительно, что её инициализация начинается при закрытии сеанса. Кто в вашем случае является вызывающей стороной и клиентом
libpam0?
LightDM?
SLiM?
Пакета hxtools в репах не наблюдаю.
Да,
такого не держим. А документация и конфиг прямо говорят, что
ofl нужен и зачем:
to support kill-on-logout. LibHX и hxtools когда-то были частью этого проекта, видимо потом отделились. В том числе поэтому пользователи
pam_mount должны страдать, я считаю. Архитектура этого решения в корне неправильна, коряквы при отмонтировании неизбежны при таком подходе.
Ну вот что не так:
В документации предлагается иной способ настройки стека и конфига
pam_mount:
1)
https://www.altlinux.org/ActiveDirectory/Login#Через_pam_mount2)
https://www.altlinux.org/SSSD/AD#Через_pam_mount
