Bug 43627

(In reply to Sergey V Turchin from comment #0)
> Из-за изменения
> https://invent.kde.org/plasma/kscreenlocker/-/commit/
> 132adacf3d01fc4adf8a873e0debc3adb17972ec
> , т.к. у нас "не как у всех", придётся ставить SGID не как раньше на
> маленькую программу kcheckpass, а на весь kscreenlocker_greet.
> 
> Может и у нас уже появился способ делать это без SGID?
> Или ничего страшного?
> 
> P.S.
> Самое интересное, что это изменение было сделано с нашей же подачи. :-)

Я не понял, что здесь написано, поэтому просто напишу, как оно устроено, может, забыли уже.

Для того, чтобы проверить пароль, нужно иметь доступ на запуск хелпера,
"у них", видимо, этот хелпер может запускать кто угодно, в то время как в схеме tcb - только члены группы chkpwd.

(Ответ для Dmitry V. Levin на комментарий #1)
> Я не понял, что здесь написано, поэтому просто напишу, как оно устроено,
Я не понял, зачем, поэтому пока буду пытаться объяснить, как оно устроено на самом деле.

> может, забыли уже.
Нет, не забыл.

Такое устройство -- проблема, т.к. я не могу SGID на тред поставить.

P.S.
С utempter ровно та же проблема.
Допустим, есть процесс, который подгружает модули с различной функциональностью.
1-й модуль проверяет пароль, 2-й делает записи в utmp.
1-й + 2-й == хрентам, но это пока до реальности не дошло.

В реальности мне на весь процесс с кучей различных модулей нужно ставить SGID на utempter?!!!

Суть в том, что разделение прав в tcb_chkpwd и utempter придумано в прошлом тысячелетии, когда в linux ещё не было поддержки нитей, поэтому рассчитано только на отдельные маленькие программки, из-за чего в текущих реалиях оно устарело и тянет на дно всё, что использует нити и загружаемые модули.

Предлагаю авторам реализовать в них некую новую функциональность для современного времени, но для которой не надо вставлять костыли в места использования, т.к. в некоторых случаях костыль принципиально невозможен(уже давно наткнулся: konsole+libdbus==utempter-idyot-na-fig).

(In reply to Sergey V Turchin from comment #2)
> (Ответ для Dmitry V. Levin на комментарий #1)
> > Я не понял, что здесь написано, поэтому просто напишу, как оно устроено,
> Я не понял, зачем, поэтому пока буду пытаться объяснить, как оно устроено на
> самом деле.
> 
> > может, забыли уже.
> Нет, не забыл.
> 
> Такое устройство -- проблема, т.к. я не могу SGID на тред поставить.
> 
> P.S.
> С utempter ровно та же проблема.
> Допустим, есть процесс, который подгружает модули с различной
> функциональностью.
> 1-й модуль проверяет пароль, 2-й делает записи в utmp.
> 1-й + 2-й == хрентам, но это пока до реальности не дошло.
> 
> В реальности мне на весь процесс с кучей различных модулей нужно ставить
> SGID на utempter?!!!

Ты привёл пример приложения с кривой архитектурой.  Видимо, его написали люди, недостаточно осведомлённые в предмете.  Их, конечно, надо обучать, вопрос только в том, кому.

(In reply to Sergey V Turchin from comment #3)
> Суть в том, что разделение прав в tcb_chkpwd и utempter придумано в прошлом
> тысячелетии, когда в linux ещё не было поддержки нитей,

К сожалению, это утверждение не соответствует действительности.
tcb и libutempter появились в 2001 году,  Поддержка threads появилась в glibc задолго до этого.

> поэтому рассчитано
> только на отдельные маленькие программки, из-за чего в текущих реалиях оно
> устарело и тянет на дно всё, что использует нити и загружаемые модули.

Адекватно подготовленные программисты не используют загружаемые привилегированные модули.

> Предлагаю авторам реализовать в них некую новую функциональность для
> современного времени, но для которой не надо вставлять костыли в места
> использования, т.к. в некоторых случаях костыль принципиально невозможен(уже
> давно наткнулся: konsole+libdbus==utempter-idyot-na-fig).

Загрузка более привилегированных модулей в менее привилегированный процесс - это нонсенс, так не бывает.  Если есть ошибки в архитектуре konsole, надо исправлять их.

(Ответ для Dmitry V. Levin на комментарий #5)
> (In reply to Sergey V Turchin from comment #3)
> > Суть в том, что разделение прав в tcb_chkpwd и utempter придумано в прошлом
> > тысячелетии, когда в linux ещё не было поддержки нитей,
> К сожалению, это утверждение не соответствует действительности.
> tcb и libutempter появились в 2001 году,  Поддержка threads появилась в
> glibc задолго до этого.
К сожалению, это утверждение не соответствует действительности, т.к. я ничего не писал про glibc.

> > поэтому рассчитано
> > только на отдельные маленькие программки, из-за чего в текущих реалиях оно
> > устарело и тянет на дно всё, что использует нити и загружаемые модули.
> Адекватно подготовленные программисты не используют загружаемые
> привилегированные модули.
Так это вы так задумали.

> > в некоторых случаях костыль принципиально невозможен(уже
> > давно наткнулся: konsole+libdbus==utempter-idyot-na-fig).
> Загрузка более привилегированных модулей в менее привилегированный процесс - 
> это нонсенс, так не бывает.
Не угадал. Там нет модулей. dbus детектит SGID и посылает.

(Ответ для Dmitry V. Levin на комментарий #4)
> Ты привёл пример приложения с кривой архитектурой.  Видимо, его написали
> люди, недостаточно осведомлённые в предмете.  Их, конечно, надо обучать,
> вопрос только в том, кому.
Кто придумал, тому и обучать.

(Ответ для Dmitry V. Levin на комментарий #5)
> К сожалению, это утверждение не соответствует действительности.
> tcb и libutempter появились в 2001 году,
Вот и получается, что уже 20 лет никакого развития, из-за чего только новые палки в колёса.

(Ответ для Sergey V Turchin на комментарий #8)
> (Ответ для Dmitry V. Levin на комментарий #5)
> > К сожалению, это утверждение не соответствует действительности.
> > tcb и libutempter появились в 2001 году,
> Вот и получается, что уже 20 лет никакого развития, из-за чего только новые
> палки в колёса.

Мы тоже появились в 2001.
Никакого развития?

(Ответ для AEN на комментарий #9)
> > Вот и получается, что уже 20 лет никакого развития, из-за чего только новые
> > палки в колёса.
> Мы тоже появились в 2001. Никакого развития?
Развитие костылей было такое, что некоторые уже сломались окончательно (в konsole, например).

В xscreensaver, кстати, та же история(kscreenlocker его тут догнал).
Он тоже весь
%attr(2711,root,chkpwd) %_bindir/%name

(In reply to Sergey V Turchin from comment #6)
> (Ответ для Dmitry V. Levin на комментарий #5)
> > (In reply to Sergey V Turchin from comment #3)
> > > Суть в том, что разделение прав в tcb_chkpwd и utempter придумано в прошлом
> > > тысячелетии, когда в linux ещё не было поддержки нитей,
> > К сожалению, это утверждение не соответствует действительности.
> > tcb и libutempter появились в 2001 году,  Поддержка threads появилась в
> > glibc задолго до этого.
> К сожалению, это утверждение не соответствует действительности, т.к. я
> ничего не писал про glibc.

Интерфейс threads в любом случае реализован в libc.

> > > в некоторых случаях костыль принципиально невозможен(уже
> > > давно наткнулся: konsole+libdbus==utempter-idyot-na-fig).
> > Загрузка более привилегированных модулей в менее привилегированный процесс - 
> > это нонсенс, так не бывает.
> Не угадал. Там нет модулей. dbus детектит SGID и посылает.

Для полноты картины нужны подробности, кто именно и как именно "детектит SGID".

(In reply to Sergey V Turchin from comment #11)
> В xscreensaver, кстати, та же история(kscreenlocker его тут догнал).

Для полноты картины нужна расшифровка, какая именно история.

(Ответ для Dmitry V. Levin на комментарий #13)
> (In reply to Sergey V Turchin from comment #11)
> > В xscreensaver, кстати, та же история(kscreenlocker его тут догнал).
> Для полноты картины нужна расшифровка, какая именно история.
Вся вышеописанная.

(Ответ для Dmitry V. Levin на комментарий #12)
> > Не угадал. Там нет модулей. dbus детектит SGID и посылает.
> Для полноты картины нужны подробности, кто именно
libdbus.

> и как именно "детектит SGID".
Хреново. setresgid() не даёт пользоваться.

Конкретно мне utempter уже не особо интересен, т.к. жить можно и без него.
sgid на весь скринлокер тоже работает, поэтому "шлите патчи".

Моё дело было проинформировать.

(In reply to Sergey V Turchin from comment #14)
> (Ответ для Dmitry V. Levin на комментарий #13)
> > (In reply to Sergey V Turchin from comment #11)
> > > В xscreensaver, кстати, та же история(kscreenlocker его тут догнал).
> > Для полноты картины нужна расшифровка, какая именно история.
> Вся вышеописанная.

С тредами? С dbus?  Какая история?

(In reply to Sergey V Turchin from comment #15)
> (Ответ для Dmitry V. Levin на комментарий #12)
> > > Не угадал. Там нет модулей. dbus детектит SGID и посылает.
> > Для полноты картины нужны подробности, кто именно
> libdbus.

В какой момент?

> 
> > и как именно "детектит SGID".
> Хреново. setresgid() не даёт пользоваться.

Как конкретно?  Что именно проверяет и как?

> Конкретно мне utempter уже не особо интересен, т.к. жить можно и без него.
> sgid на весь скринлокер тоже работает, поэтому "шлите патчи".

sgid на что?

> Моё дело было проинформировать.

Из описанного понятно, что где-то что-то почему-то не работает, но не более того.

(Ответ для Dmitry V. Levin на комментарий #13)
> (In reply to Sergey V Turchin from comment #11)
> > В xscreensaver, кстати, та же история(kscreenlocker его тут догнал).
> Для полноты картины нужна расшифровка, какая именно история.
Как раз та, что исключена из цитаты. коментарий#11

А вот и косяк всплыл. Вся функциональность dbus в kscreenlocker теперь идёт лесом. Переключатель раскладки кравиатуры отвалился.

(Ответ для Dmitry V. Levin на комментарий #12)
> > dbus детектит SGID и посылает.
> Для полноты картины нужны подробности, кто именно и как именно "детектит
> SGID".
В dbus функция _dbus_check_setuid .

(Ответ для AEN на комментарий #9)
> Мы тоже появились в 2001.
> Никакого развития?
Ну, почему же? У меня уже семья и 2-е детей, например.

(Ответ для Dmitry V. Levin на комментарий #4)
> Ты привёл пример приложения с кривой архитектурой.
Ок, упрощаю архитектуру:
есть пользовательский процесс, в котором используется проверка пользовательского пароля и создание записей в utmp. У нас такое невозможно.

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

Я предлагаю не заморачивать никого подготовкой каких-либо блюд в предпочитаемом виде, а для начала решить ну хоть один насущный:

Процесс проверки своего пароля несовместим libdbus.
В dbus функция _dbus_check_setuid посылает даже при наличия в вызывающем процессе костылей обхода.

> Процесс проверки своего пароля
/usr/libexec/kf5/kscreenlocker_greet из пакета plasma5-kscreenlocker-5.25

> решить ну хоть один насущный:
> Процесс проверки своего пароля несовместим libdbus.
> В dbus функция _dbus_check_setuid посылает даже при наличия в вызывающем
> процессе костылей обхода.
Есть хоть какие-то идеи?

Я прошу в рамках этого бага решить конкретную проблему:
несовместимость tcb_chkpwd и D-Bus.

P.S.
Если есть желание решать какие-то комплексы, предлагаю делать это не здесь.

See Also: bug#43701

(In reply to Sergey V Turchin from comment #22)
> (Ответ для Dmitry V. Levin на комментарий #4)
> > Ты привёл пример приложения с кривой архитектурой.
> Ок, упрощаю архитектуру:
> есть пользовательский процесс, в котором используется проверка
> пользовательского пароля и создание записей в utmp. У нас такое невозможно.

У нас именно это было реализовано в пакете screen более 20 лет назад:

%pre
/usr/sbin/groupadd -r -f screen

%post
ln -f %_libexecdir/chkpwd/tcb_chkpwd %_libexecdir/screen/
ln -f %_libexecdir/utempter/utempter %_libexecdir/screen/

%preun
if [ $1 -eq 0 ]; then
        rm -f %_libexecdir/screen/{tcb_chkpwd,utempter}
fi

%triggerin -- pam_tcb >= 0.9.7.1
ln -f %_libexecdir/chkpwd/tcb_chkpwd %_libexecdir/screen/

%triggerin -- libutempter >= 1.0.6
ln -f %_libexecdir/utempter/utempter %_libexecdir/screen/

%files
%attr(2711,root,screen) %_bindir/screen
%attr(710,root,screen) %dir %_libexecdir/screen
%attr(2711,root,shadow) %ghost %_libexecdir/screen/tcb_chkpwd
%attr(2711,root,utmp) %ghost %_libexecdir/screen/utempter

(In reply to Dmitry V. Levin from comment #29)
> У нас именно это было реализовано в пакете screen более 20 лет назад:
А какой смысл тогда всейвообще так делать?
Не проще chmod o+x сделать для /usr/lib/utempter и /usr/lib/chkpwd ?

(In reply to Sergey V Turchin from comment #30)
> А какой смысл тогда всейвообще так делать?
А какой смысл тогда всей этой затеи с правами доступа?

(In reply to Dmitry V. Levin from comment #29)
> У нас именно это было реализовано в пакете screen более 20 лет назад:
Тот местячковый костыль на реализацию ну никак не тянет.
Или это прямое предложение общесистемно испортить /etc/pam.d/system-auth-* ?