Прошу реализовать совместимость по поведению и набору параметров (тот же -m) с принятой во многих мейнстримовых проектах версией su из coreutils. Это позволит обеспечить совместимость как по документации, так и по использованию всяких проприетарных программ (например, Postgres Plus Advanced Server).
Дада, и поведение без -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) > Наверное, стоит начать собирать ссылки на "успешные истории" Это не сработало за все годы. Возможно, надо отправлять каждого пользователя прямо к Диме по почте на консультацию.
