Bug 23700

Дада, и поведение без -l тоже.

Всё же жить можно и так. Не distro-blocker

Я бы еще попросил не закрывать pty при -l, иначе во всех kdesu приходиться отрывать -l, т.к. перестает работать.

Дима, то, что ты убрал зависимость на 23155 говорит о том, что время исправления не определено?

(In reply to comment #4)
> Дима, то, что ты убрал зависимость на 23155 говорит о том, что время
> исправления не определено?

Не только время не определено, но и направление движения сейчас уже не вполне ясно, см. http://openwall.com/lists/oss-security/2011/06/02/3 и далее по треду.

Тем временем в openSUSE и Fedora su переезжает из coreutils в util-linux:
http://lists.gnu.org/archive/html/coreutils/2012-05/msg00101.html

Переезжают в каком виде? В каком у них или в каком сейчас у нас?

Наверное, стоит начать собирать ссылки на "успешные истории"
http://forum.altlinux.org/index.php/topic,26167.0.html

https://forum.altlinux.org/index.php?topic=37286.msg296110#msg296110

Вот здесь тоже человек забыл про '-'
https://forum.altlinux.org/index.php?topic=40051.msg317487#msg317487

Дима, несмотря на то, что кто-то где-то куда-то переехал - поведение su у всех и у нас до сих пор отличается. у fc su собран из util-linux, наверное нам тоже стоит переехать на него.

Предлагаю попробовать решить это к p9.
Кто-то есть, кто расчитывает на наше нестандартное поведение su ?

При этом у su нет "стандартного" поведения.

Термин "стандартное" можно заменить на "общепринятое".
Важно что все понимают о чём речь - наши новые пользователи постоянно натыкаются на то, что su у нас и su в других популярных дистрибутивах ведёт себя по разному.

Так вопрос остаётся  - кто-то у нас расчитывает на несоответствующее общепринятому поведение su ?

(In reply to comment #15)
> Так вопрос остаётся  - кто-то у нас расчитывает на несоответствующее
> общепринятому поведение su ?

На какое именно?  На поведение без -l?  Это хороший вопрос.

Да, есть ли кто-то, кому действительно нужен su без -l по умолчанию ?

Может быть соберёшь тестовое задание с другим su, а я подумаю как это проверить ?

(В ответ на комментарий №16)
> На поведение без -l?  Это хороший вопрос.
Этим вопросом пользователи уже за много лет задолбали, задалбывают и будут
задалбывать вечно. Только они его перефразируют, как: "Почему не работает
<что-то-случайное>?".

Почему вечно ? Я верю в то, что Дима с головой и исправит эту мелкую несуразность.

(В ответ на комментарий №19)
> Почему вечно ? Я верю в то, что Дима с головой и исправит эту мелкую
> несуразность.
Я тоже верю, но вдруг это будет после вечности? ;-)

(В ответ на комментарий №16)
> (In reply to comment #15)
> > Так вопрос остаётся  - кто-то у нас расчитывает на несоответствующее
> > общепринятому поведение su ?
> На какое именно?
У меня, наоборот, обратная проблема из-за закрытия при -l за собой pty, через
который kdesu работает, поэтому приходится там отрывать -l.

Патчей для нормальной работа ни у кого я не видел, следовательно в них такого
поведения нет.

P.S.
Мне бы даже помог отдельный пакет с другим su, который ставиться без
конфликтов.

(В ответ на комментарий №21)
> (В ответ на комментарий №16)
> > (In reply to comment #15)
> > > Так вопрос остаётся  - кто-то у нас расчитывает на несоответствующее
> > > общепринятому поведение su ?
> > На какое именно?
> У меня, наоборот, обратная проблема из-за закрытия при -l за собой pty, через
> который kdesu работает, поэтому приходится там отрывать -l.
> 
> Патчей для нормальной работа ни у кого я не видел, следовательно в них такого
> поведения нет.
> 
> P.S.
> Мне бы даже помог отдельный пакет с другим su, который ставиться без
> конфликтов.
Быть может нам нужно поступить как с bash и sh — чтобы был su для людей и su для скриптов?

Для скриптов наверняка можно сделать su без suid, работающий под рутом.

(In reply to comment #14)
> Термин "стандартное" можно заменить на "общепринятое".
> Важно что все понимают о чём речь - наши новые пользователи постоянно
> натыкаются на то, что su у нас и su в других популярных дистрибутивах ведёт
> себя по разному.

Они даже не знают, что такое PATH. Здесь вопрос: а что дает отсутствие sbin в PATH не рута, кроме "ложных" сообщений "command not found"?

(В ответ на комментарий №24)
> (In reply to comment #14)
> > Термин "стандартное" можно заменить на "общепринятое".
> > Важно что все понимают о чём речь - наши новые пользователи постоянно
> > натыкаются на то, что su у нас и su в других популярных дистрибутивах ведёт
> > себя по разному.
> 
> Они даже не знают, что такое PATH. Здесь вопрос: а что дает отсутствие sbin в
> PATH не рута, кроме "ложных" сообщений "command not found"?

Повесьте, пожалуйста, по этому поводу свою отдельную багу и спрашивайте там.

Есть предложение собрать общепринятую (совместимую с другими дистрибутивами) реализацию su из пакета util-linux под другим именем и использовать её через alias.

@legion, что скажешь ?

Второй вариант - поправить эту реализацию для изменения поведения по умолчанию, но на это нужно одобрение @ldv. Дима, что скажешь ?

(Ответ для Anton Farygin на комментарий #26)
> Есть предложение собрать общепринятую (совместимую с другими дистрибутивами)
> реализацию su из пакета util-linux под другим именем и использовать её через
> alias.
> 
> @legion, что скажешь ?

Я посмотрел на две версии и код совсем разный. Поэтому я беспокоюсь, что появяться какие-нибудь регрессии. В идеале нужно вычитывать код util-linux/su и сравнивать.

Я сделал тестовое задание. Прошу заинтересованных проверить:

http://webery.altlinux.org/task/254961

> Я сделал тестовое задание. Прошу заинтересованных проверить:
Как? В нём же упакован /bin/su .

(Ответ для Alexey Gladkov на комментарий #28)
> Я посмотрел на две версии и код совсем разный. Поэтому я беспокоюсь, что
> появяться какие-нибудь регрессии.
Я больше беспокоюсь, что Дима этот обсолет su не пропустит, поэтому и предлагалось сделать alias, чтоб не всем.

P.S.
А если Дима не против, то так даже лучше.

(Ответ для Alexey Gladkov на комментарий #28)
> беспокоюсь, что появяться какие-нибудь регрессии
У меня /usr/libexec/kf5/kdesu обломался из-за того, что пропатчен не обламываться с текущим su.

(Ответ для Sergey V Turchin на комментарий #29)
> > Я сделал тестовое задание. Прошу заинтересованных проверить:
> Как? В нём же упакован /bin/su .

Эм. Поставить util-linux и поверить su из него ?


(Ответ для Sergey V Turchin на комментарий #30)
> Я больше беспокоюсь, что Дима этот обсолет su не пропустит, поэтому и
> предлагалось сделать alias, чтоб не всем.

Если предложение было сделать подпакет с другим именем утилиты, то я против. Это не дело иметь разные реализации такой системной утилиты. Либо используем одну реализацию, либо другую.

(Ответ для Alexey Gladkov на комментарий #32)
> Либо используем одну реализацию, либо другую.
Значит, надо искать. Могут быть ещё регрессии.

Лёша, спасибо. Берём в тестирование и будем искать регрессии.

$su -l root
su: Сбой при проверке подлинности
$

при этом в логах
июл 16 10:08:39 zerg.malta.altlinux.ru audit[739741]: USER_AUTH pid=739741 uid=500 auid=500 ses=2 msg='op=PAM:authentication grantors=? acct="root" exe="/bin/su" hostname=zerg.malta.altlinux.ru addr=? terminal=pts/12 res=failed'
июл 16 10:08:39 zerg.malta.altlinux.ru kernel: audit: type=1100 audit(1594883319.277:3932): pid=739741 uid=500 auid=500 ses=2 msg='op=PAM:authentication grantors=? acct="root" exe="/bin/su" hostname=zerg.malta.altlinux.ru addr=? terminal=pts/12 res=failed'
июл 16 10:08:39 zerg.malta.altlinux.ru su[739741]: FAILED SU (to root) zerg on pts/12

(Ответ для Sergey V Turchin на комментарий #35)
> $su -l root
> su: Сбой при проверке подлинности
> $

Ага. Спасибо, Серёг! Обновил задание. Должно быть исправлено.

поставил себе, работает.

man 1 su в русском варианте остался от SimplePamApps, но это уже в другом пакете исправлять.

А у меня kdesu заработал.

Не знаю, правда, достаточно ли нам этого будет. Надо у других посмотреть.

[zerg@zerg ~]$ su -
Пароль: 
[root@zerg ~]# set| grep zerg
HOSTNAME=zerg.malta.altlinux.ru
[root@zerg ~]# 
[root@zerg ~]# logout
[zerg@zerg ~]$ su
Пароль: 
[root@zerg zerg]# set| grep zerg
BASH_ENV=/home/zerg/.bashrc
GIT_AUTHOR_EMAIL=zerg@altlinux.org
GIT_COMMITTER_EMAIL=zerg@altlinux.org
HOSTNAME=zerg.malta.altlinux.ru
LOGNAME=zerg
MAIL=/var/mail/zerg
PWD=/home/zerg
SESSION_MANAGER=local/zerg.malta.altlinux.ru:@/tmp/.ICE-unix/4505,unix/zerg.malta.altlinux.ru:/tmp/.ICE-unix/4505
SSH_AUTH_SOCK=/home/zerg/.ssh/agent
USER=zerg
[root@zerg zerg]#

Created attachment 8875 [details]
В Ubuntu получше

А что в kubuntu до su с set|grep kubuntu  ?

т.е. - возможно что у них нет тех переменных, которые есть у нас.

в ubuntu su из другого пакета, уж если сравнивать поведение, то с fedora, в которой он из util-linux.

В man 1 su описано то, что @zerg увидел в su и env, это поведение выглядит приемлемым для su без -l

LOGNAME=zerg
MAIL=/var/mail/zerg
PWD=/home/zerg
USER=zerg

Мне кажется, что это всё у нас лишнее. В Убунте этого нет.

(Ответ для Anton Farygin на комментарий #42)
> А что в kubuntu до su с set|grep kubuntu  ?
MAIL нет, разве что.

В debian-bases переменные окружения сбрасываются так:
https://github.com/shadow-maint/shadow/blob/master/src/su.c#L838

Но вроде как debian подумывает перейти на su из util-linux, так что будет везде примерно одинаково.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905478

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

Может и Дима для протокола что-нибудь нам напишет?

Я планирую посмотреть код su в util-linux, но у меня очередь на большие code review.
Сперва у меня apt, который готовит imz@, и это срочно.
Потом strace, там тоже порядочно накопилось.
Потом hasher-priv, который уже сделал legion@ и ждёт, когда я посмотрю.

Ок, но прошу иметь ввиду, что эта проблема за последние 15 лет уже задолбала.

Думаю, эта проблема в ближайшие 10 лет не решится.

(Ответ для Alexey Gladkov на комментарий #52)
> Думаю, эта проблема в ближайшие 10 лет не решится.

ну apt уже почти скоро, правда я не знаю, смотрит ли его Дима.

Наткнулся на ещё один вариант несовместимости su в Альте: он не поддерживает "--".  Это обсуловлено тем, что в отличие от традиционных реализаций он собран не с getopt-ом. Кажется, что перейти на getopt, ничего не сломав, куда проще, чем разобраться с -l и -m. Поэтому я бы выделил свою просьбу в отдельный запрос, но Алексей Новодворский предложил написать сюда.

(Ответ для Dmitry V. Levin на комментарий #5)
> Не только время не определено, но и направление движения сейчас уже не
> вполне ясно
За 10 лет что-то прояснилось?

Судя по валу вопросов от новых пользователей, в частности, в @alt_linux, которые внезапно обнаруживают, что "su" надо было вызывать как "su -", надо как-то эту проблему решать, особенно если учесть, что по известным причинам ожидается массовый наплыв новых пользователей дистрибутивов Альт.

Временно эту проблему можно решить, если для любого нового логина в системе вызов утилиты "su" будет сопровождаться предупреждением (на двух языках?), о том, что обычный вызов - это "su -", а в виде "su" вызов возможен, если только вызывающий знает для чего конкретно нужно именно так.

Можно ещё и вопрос включить типа "Знает ли пользователь о возможных разрушительных последствиях, вызывая "su" вместо "su -" (НЕТ/да)?" Хотя это может сломать поведение, конечно.

О том как убрать это предупреждение, должно быть написано где-то в другом месте, где и отличие объясняется в явном виде.

Как-то так. Возможно.

(Ответ для Sergey V Turchin на комментарий #3)
> Я бы еще попросил не закрывать pty при -l, иначе во всех kdesu приходиться
> отрывать -l, т.к. перестает работать.
Это уже неактуально.

(Ответ для Zerg на комментарий #8)
> Наверное, стоит начать собирать ссылки на "успешные истории"
Это не сработало за все годы. Возможно, надо отправлять каждого пользователя прямо к Диме по почте на консультацию.