46816 2023-07-08 12:34:01 +0300 glibc: lchmod is a stub -- несовместимость со сторонними приложениями 2025-01-23 12:54:21 +0300 1 1 4 Development Sisyphus glibc unstable all Linux NEW P5 major --- 1 asheplyakov glebfm aris asheplyakov glebfm iv lav ldv rider sin vt qa-sisyphus oldest_to_newest 229237 0 asheplyakov 2023-07-08 12:34:01 +0300 # mknod -m 666 cdev c 1 3 mknod: cannot set permissions of 'cdev': Function not implemented 408296 umask(000) = 022 408296 umask(022) = 000 408296 mknodat(AT_FDCWD, "cdev", S_IFCHR|0666, makedev(0x1, 0x3)) = 0 408296 write(2, "mknod: ", 7) = 7 408296 write(2, "cannot set permissions of 'cdev'", 32) = 32 408296 write(2, ": Function not implemented", 26) = 26 408296 write(2, "\n", 1) = 1 Причина вот в этом патче: commit 12faabce398086b0c1eec646b5849e09c12aa480 Author: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org> Date: Wed Dec 16 22:04:10 2020 +0300 Revert "io: Implement lchmod using fchmodat [BZ #14578]" This reverts commit 6b89c385d8bd0700b25bac2c2d0bebe68d5cc05d. See also: https://sourceware.org/bugzilla/show_bug.cgi?id=26401 Во-первых, у некоторых архитектур (в частности LoongArch) реализация lchmod через fchmodat - единственная. Во-вторых, с этим патчем на ВСЕХ архитектурах fchmodat не соответствует POSIX.2008. Это приводит к тому, что некоторые авторы (и/или сопровождающие) приложений избегают *at функций, и вместо них используют устаревшие аналоги, подверженные гонкам с символьными ссылками (см. https://www.youtube.com/watch?v=4JrY-DntoyU) 229245 1 ldv 2023-07-08 14:45:10 +0300 К сожалению, fchmodat(..., AT_SYMLINK_NOFOLLOW) не реализовано в ядре: у сисколла fchmodat вообще нет аргумента, через который можно было бы передать флаги, а реализация в glibc использует /proc, в результате чего получается https://sourceware.org/bugzilla/show_bug.cgi?id=26401 Так что баг не по адресу. Реализуйте fchmodat4 в ядре, и будет всем счастье. 229246 2 ldv 2023-07-08 14:49:36 +0300 (In reply to Alexey Sheplyakov from comment #0) > Во-первых, у некоторых архитектур (в частности LoongArch) реализация lchmod > через fchmodat - единственная. Во-первых, реализации lchmod нет ни на одной архитектуре. Есть либо заглушка, либо кривулька, причём одинаковая на всех архитектурах. > Во-вторых, с этим патчем на ВСЕХ архитектурах fchmodat не соответствует > POSIX.2008. Это приводит к тому, что некоторые авторы (и/или сопровождающие) > приложений избегают *at функций, и вместо них используют устаревшие аналоги, > подверженные гонкам с символьными ссылками (см. > https://www.youtube.com/watch?v=4JrY-DntoyU) Вы что-то перепутали, этот патч вообще не затрагивает ни интерфейс fchmodat, ни её реализацию в glibc. 229247 3 glebfm 2023-07-08 14:55:38 +0300 (In reply to Alexey Sheplyakov from comment #0) > # mknod -m 666 cdev c 1 3 > mknod: cannot set permissions of 'cdev': Function not implemented А ещё mknod не использует lchmod из glibc, он пользуется реализацией из gnulib, так что именно в этом случае стоит смотреть туда. 229249 4 asheplyakov 2023-07-08 17:01:06 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #3) > (In reply to Alexey Sheplyakov from comment #0) > > # mknod -m 666 cdev c 1 3 > > mknod: cannot set permissions of 'cdev': Function not implemented > > А ещё mknod не использует lchmod из glibc, он пользуется реализацией из > gnulib, так что именно в этом случае стоит смотреть туда. Без упомянутого патча ("Revert "io: Implement lchmod using fchmodat [BZ #14578]") mknod в частности и lchmod вообще работает на LoongArch. 229250 5 asheplyakov 2023-07-08 17:13:48 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #3) > (In reply to Alexey Sheplyakov from comment #0) > > # mknod -m 666 cdev c 1 3 > > mknod: cannot set permissions of 'cdev': Function not implemented > > А ещё mknod не использует lchmod из glibc, он пользуется реализацией из > gnulib, так что именно в этом случае стоит смотреть туда. Пострадал не только mknod. Но с mknod проблему легче всего воспроизвести. 229252 6 glebfm 2023-07-08 17:37:39 +0300 А coreutils и остальные пострадавшие пакеты были собраны с каким-то неальтовым glibc? Видимо, придётся пересобрать всё затронутое. 229267 7 sin 2023-07-09 15:11:00 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #6) > А coreutils и остальные пострадавшие пакеты были собраны с каким-то > неальтовым glibc? Видимо, придётся пересобрать всё затронутое. Сначала нужно решить проблему, которая возникала. Я так и не понял пока предложено л и решение. 229268 8 ldv 2023-07-09 15:25:43 +0300 (In reply to Evgeny Sinelnikov from comment #7) > (Ответ для Gleb F-Malinovskiy на комментарий #6) > > А coreutils и остальные пострадавшие пакеты были собраны с каким-то > > неальтовым glibc? Видимо, придётся пересобрать всё затронутое. > > Сначала нужно решить проблему, которая возникала. Я так и не понял пока > предложено л и решение. У вас проблема, что вы собрали gnulib'ные пакеты с не-альтовой glibc, в результате они закладываются на семантику новой glibc'шной обёртки lchmod, которая не работает без /proc, и которой по этой причине в альтовой glibc нет. По-видимому, для решения проблемы вам достаточно пересобрать gnulib'ные пакеты с альтовой glibc. В любом, случае никакой looongarch'евой специфики тут не было и нет. 229269 9 ldv 2023-07-09 15:26:53 +0300 Кстати, кто-нибудь в курсе, какова судьба https://lore.kernel.org/lkml/20190717012719.5524-1-palmer@sifive.com/T/#mebf5710a5f551236940b9b5014f2b760ec8f8543 ? 229270 10 sin 2023-07-09 17:23:36 +0300 (Ответ для Dmitry V. Levin на комментарий #9) > Кстати, кто-нибудь в курсе, какова судьба > https://lore.kernel.org/lkml/20190717012719.5524-1-palmer@sifive.com/T/ > #mebf5710a5f551236940b9b5014f2b760ec8f8543 > ? С трудом могу сказать о причинах, но воз и ныне нам, а патчи протухли. Этот fchmodat4() планировалось добавить 434 номером, с тех пор в апстримном v6.4 добавлен уже 450 номер, а предлагаемого системного вызова нет, как нет: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/include/uapi/asm-generic/unistd.h?h=v6.4 229272 11 sin 2023-07-09 17:38:01 +0300 (Ответ для Dmitry V. Levin на комментарий #8) > (In reply to Evgeny Sinelnikov from comment #7) > > (Ответ для Gleb F-Malinovskiy на комментарий #6) > > > А coreutils и остальные пострадавшие пакеты были собраны с каким-то > > > неальтовым glibc? Видимо, придётся пересобрать всё затронутое. > > > > Сначала нужно решить проблему, которая возникала. Я так и не понял пока > > предложено л и решение. > > У вас проблема, что вы собрали gnulib'ные пакеты с не-альтовой glibc, в > результате они закладываются на семантику новой glibc'шной обёртки lchmod, > которая не работает без /proc, и которой по этой причине в альтовой glibc > нет. > По-видимому, для решения проблемы вам достаточно пересобрать gnulib'ные > пакеты с альтовой glibc. > В любом, случае никакой looongarch'евой специфики тут не было и нет. Я бы поставил вопрос иначе. У нас всех эта проблема блокирует портирование лунгарча, в принципе. А решение, которое бы удовлетворило возможность запуска lchmod без /proc, отсутствует. Я считаю, что эта проблема не должна и не может блокировать сам процесс портирования. Требование же, связанное с таким abi glibc, которое бы работало для lchmod без /proc, наконец-то озвучено. Это совершенно неочевидное требование. Давайте его зафиксируем. Также давайте определимся, что мы делаем пока не предложено технических решений для удовлетворения зафиксированному выше требованию? На текущий момент, предложение добавить в ядро новый системный вызов по какой-то причине не принято. Что мы можем с этим поделать? Приостанавливать работу по портированию мы по этой причине, очевидно, не можем. Найти ресурс и заняться этой проблемой мы можем. Сроки решения этой проблемы измеряются месяцами и годами. Или я не прав? Если изложенное выше не расходится с действительностью, то давайте говорить, что это "нас" всех одна и таже проблема, причём связанная с разными, новыми аппараратными платформами. Когда мы её решим, всё, очевидно, придётся разок пересобрать. 229285 12 asheplyakov 2023-07-09 20:42:03 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #6) > А coreutils и остальные пострадавшие пакеты были собраны с каким-то > неальтовым glibc? Видимо, придётся пересобрать всё затронутое. Сломана glibc, вот её и чинить надо - пересобрать без Вашего патча. 229286 13 asheplyakov 2023-07-09 20:52:16 +0300 (Ответ для Dmitry V. Levin на комментарий #8) > (In reply to Evgeny Sinelnikov from comment #7) > > (Ответ для Gleb F-Malinovskiy на комментарий #6) > > > А coreutils и остальные пострадавшие пакеты были собраны с каким-то > > > неальтовым glibc? Видимо, придётся пересобрать всё затронутое. > > > > Сначала нужно решить проблему, которая возникала. Я так и не понял пока > > предложено л и решение. > > У вас проблема, что вы собрали gnulib'ные пакеты с не-альтовой glibc, в > результате они закладываются на семантику новой glibc'шной обёртки lchmod, > которая не работает без /proc, и которой по этой причине в альтовой glibc нет. Проблема у Вас, а точнее их три. 1) Вы почему-то решили, что glibc в частности и userspace Linux вообще должны работать без /proc. Никто никогда не давал таких гарантий. 2) Вы считаете нормальным на ровном месте устроить несовместимость с остальным миром. 3) Вы считаете нормальным принимать подобные решения единолично. > По-видимому, для решения проблемы вам достаточно пересобрать gnulib'ные > пакеты с альтовой glibc. А со сторонними приложениями, которые используют lchmod, что делать? > В любом, случае никакой looongarch'евой специфики тут не было и нет. Тут согласен. 229287 14 asheplyakov 2023-07-09 20:56:44 +0300 Пересобрал glibc без этого патча на x86_64, и -- о чудо -- у меня заработал принтер hp laserjet p1102w. Раньше приходилось контейнер с Debian держать. Видимо, где-то ему нужна рабочая lchmod 229288 15 asheplyakov 2023-07-09 21:01:59 +0300 (Ответ для Evgeny Sinelnikov на комментарий #11) > Я бы поставил вопрос иначе. У нас всех эта проблема блокирует портирование > лунгарча, в принципе. А решение, которое бы удовлетворило возможность > запуска lchmod без /proc, отсутствует. > > Я считаю, что эта проблема не должна и не может блокировать сам процесс > портирования. Требование же, связанное с таким abi glibc, которое бы > работало для lchmod без /proc, наконец-то озвучено. > > Это совершенно неочевидное требование. Давайте его зафиксируем. Возможность работы без /proc никем и ничем не гарантируется (и это относится не только к glibc). > Также давайте определимся, что мы делаем пока не предложено технических > решений для удовлетворения зафиксированному выше требованию? На текущий > момент, предложение добавить в ядро новый системный вызов по какой-то > причине не принято. Что мы можем с этим поделать? > > Приостанавливать работу по портированию мы по этой причине, очевидно, не > можем. Найти ресурс и заняться этой проблемой мы можем. Сроки решения этой > проблемы измеряются месяцами и годами. Или я не прав? > > Если изложенное выше не расходится с действительностью, то давайте говорить, > что это "нас" всех одна и таже проблема, причём связанная с разными, новыми > аппараратными платформами. Проблема не ограничена "новыми" платформами и проявляется на x86_64. > Когда мы её решим, всё, очевидно, придётся разок пересобрать. А сторонние приложения (доступные только в виде бинарных rpm) тоже пересобирать? Или подгружать lchmod через LD_PRELOAD? 229291 16 ldv 2023-07-09 21:49:12 +0300 Давайте я расскажу очевидные вещи, которые, видимо, не все понимают. Реализация lchmod через /proc в glibc появилась в glibc-2.32 (3 года назад), до этого там была заглушка. У новой реализации нет новой версии (считается, что это деталь реализации), поэтому приложение, слинкованное с новой реализацией lchmod, не может рассчитывать, что во время работы вместо lchmod не будет заглушки. По этой причине сторонние приложения вообще не могут полагаться на то, что lchmod - это рабочая реализация, а не заглушка, и так будет до тех пор, пока у новой реализации не появится версионирование. На практике, к сожалению, были приложения, которые считали, что если во время сборки lchmod - это не заглушка, то и во время работы lchmod не будет заглушкой. Вероятно, такие приложения есть в Сизифе и сейчас. 229293 17 sin 2023-07-09 22:38:05 +0300 Я думаю, что следует отличать и рассматривать отдельно: - пересмотр ранее принятых технических решений (даже если они недокументированы или, вообще, относятся к особенностям развития апстрима); и - сохранение целостности всех портов ранее принятым решениям. Текущая задача, всё-таки рассматривается не как пересмотр ранее принятых решений, а как проблема связанная с блокированием работы над портами, работы над которыми не могут быть продолжены без отхода от требований по ранее принятым решениям. Хочу обратить внимание на то, что ранее предложенный к рассмотрению патч для ядра с добавлением fchmodat4() был сделан, судя по всему, для поддержки RiscV. То есть аналогичную проблему мы имеем, скорее всего, и на этой архитектуре. Не могу сказать, что вариант "реализуйте fchmodat4 в ядре, и будет всем счастье" является достижимым в какие-то разумные сроки для того, чтобы не заблокоироваться на нём. При этом, если на RiscV возникала анлогичная проблема, то хотелось бы уточнить: "А как она у нас решена для этой архитектуры?" Это несложно проверить: http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/riscv64/Sisyphus/riscv64/SRPMS.classic/glibc-2.35.0.6.491f2e-alt0.2.rv64.src.rpm Смею предположить, что эта проблема сейчас решена для RiscV точно также, как предлагается для лунгарча. В ином случае мы бы сейчас получили блокировку и для этой архитектуры. Ну, то есть, я вообще не понимаю цель данного обсуждения, если не пытаться найти разумный компромисс. Если мы ставим себе задачи "исправить апстрим", то эта задача не должна превращаться в то, что мы больше ничего не можем сделать пока апстрим не исправлен. Итого: - у нас имеются новые аппаратные архитекутры, портирование которых блокируется решениями принятыми для glibc-2.32 (ажно ещё 3 года назад); - у нас имеются в связи с этими решениями несовместимости со сторонними приложениями, даже в самом сизифе и даже для x86_64; - "правильное" решение предполагает появление в ядре нового системного вызова ("Реализуйте fchmodat4 в ядре, и будет всем счастье."); - на текущий момент, для продолжения работы над новыми аппаратными архитекутрами, де-факто принято единственно возможное решение (так ли это?) - откатить изменения, принятые для glibc-2.32 ещё 3 года назад. Какое решение мы пытаемся принять сейчас? Я считаю, что мы обсуждаем, по сути, два решения: - Стоит ли принять в сизиф glibc, для новых аппаратных архитектур, с другим glibc-abi? То есть признать ли на уровне пакетов в основном репозитории то, что творится де-факто в догоняющих репозиториях? и - А не откатить ли все это дело для всех архитектур, признав, что решение принятое в glibc-2.32 (ещё 3 года назад) было преждевременным для задач, решаемых в сизифе? Что важнее? Следуя каким компромиссам мы сразу не откатили это апстримное исправление? Ответ на первый вопрос я бы предложил всё-таки принять положительный. Для ответа на второй вопрос у меня не хватает аргументов. Я не понимаю с какой целью было принято в апстриме соответствующее решение. Не очень понятно что должен делать автор "стороннего приложения, если вообще не может полагаться на то, что lchmod - это рабочая реализация, а не заглушка". Какие рекомендации для разработчика тут имеются? Почему мы не занялись тогда ретрансляцией этой проблемы и исправлением её для таких приложений в Сизифе? Имеется ли техническая возможность их исправить без предварительных правок других системных компонент, вроде ядра? 229294 18 sin 2023-07-09 22:46:47 +0300 Да, вопросы, которые я попытался сформулировать могут выглядеть очевидными. Но было бы неплохо, чтобы все в деталях разобрались о чем, в сущности, идёт речь. Я думаю, что смогу разобраться и сам, но это будет дольше. А тема-то уже мохнатая: https://unix.stackexchange.com/questions/224979/why-do-linux-posix-have-lchown-but-not-lchmod 229295 19 glebfm 2023-07-09 23:31:31 +0300 Проблема есть и она настоящая, но важно, что loongarch64 ничем не отличается от других архитектур, и там это ничего не блокирует, всего лишь нужно пересобрать несколько пакетов. 229296 20 sin 2023-07-10 00:15:53 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #19) > Проблема есть и она настоящая, но важно, что loongarch64 ничем не отличается > от других архитектур, и там это ничего не блокирует, всего лишь нужно > пересобрать несколько пакетов. А можно уточнить каких конкретно? И, наверное, речь не о просто 229297 21 sin 2023-07-10 00:17:51 +0300 Наверное, речь не о "просто пересобрать". И вот эта исходная проблема: # mknod -m 666 cdev c 1 3 mknod: cannot set permissions of 'cdev': Function not implemented Она как решаться, в этом случае, должна? 229298 22 glebfm 2023-07-10 00:24:31 +0300 (In reply to Evgeny Sinelnikov from comment #20) > А можно уточнить каких конкретно? Все те, которые после пересборки прекратят пытаться использовать заглушку lchmod. (In reply to Evgeny Sinelnikov from comment #21) > И вот эта исходная проблема: > # mknod -m 666 cdev c 1 3 > mknod: cannot set permissions of 'cdev': Function not implemented > > Она как решаться, в этом случае, должна? Просто пересобрать с альтовой glibc. 229299 23 ldv 2023-07-10 00:37:34 +0300 (In reply to Gleb F-Malinovskiy from comment #22) > (In reply to Evgeny Sinelnikov from comment #20) > > А можно уточнить каких конкретно? > Все те, которые после пересборки прекратят пытаться использовать заглушку > lchmod. $ cd beehive/logs/Sisyphus/x86_64/latest/success && grep -Fl 'checking for lchmod... no' * bacula13-13.0.3-alt2 coreutils-9.1.0.8.e08752-alt1 cpio-2.13-alt1 dc3dd-7.3.0-alt1_1 emacs-28.2-alt2.1 fakechroot-2.20.1-alt3 fakeroot-1.29-alt3 lftp-4.9.2-alt1 libarchive-3.6.1-alt2 libexplain-1.4-alt3 man-db-2.11.2-alt1 patch-2.7.6.0.27.7623-alt1 python-2.7.18-alt10 rsync-3.2.7-alt1 rsync-ovz-3.1.3-alt3 ruby-3.1.2-alt2.1 tar-1.34.0.16.12d67f44-alt1 xar-1.6.1-alt4 229300 24 ldv 2023-07-10 00:49:35 +0300 Продолжаем ликбез. Когда AC_CHECK_FUNC из GNU autoconf проверяет наличие функции, специально проверяются макросы, которые предоставляет /usr/include/gnu/stubs.h, для того, чтобы stub не считался за существующую функцию. 229302 25 asheplyakov 2023-07-10 07:14:21 +0300 (Ответ для Dmitry V. Levin на комментарий #24) > Продолжаем ликбез. Мало того, что ВЫ создали проблему там, где её не было, так ещё и грубите. > Когда AC_CHECK_FUNC из GNU autoconf проверяет наличие функции, специально > проверяются макросы, которые предоставляет /usr/include/gnu/stubs.h, для > того, чтобы stub не считался за существующую функцию. Мимо. Дважды мимо. 1) Что делать с уже существующими сторонними бинарниками, которые используют lchmod? Очевидно, что со временем таких бинарников будет всё больше. 2) GNU autoconf -- это ни о чём. Люди (авторы приложений) давно проголосовали ногами, и перешли кто на meson, кто на cmake. 3) Ну проверил, и что дальше? Таскать с собой свою libc, в которой таки есть lchmod? 229303 26 asheplyakov 2023-07-10 07:15:33 +0300 (Ответ для Evgeny Sinelnikov на комментарий #21) > Наверное, речь не о "просто пересобрать". > > И вот эта исходная проблема: > # mknod -m 666 cdev c 1 3 > mknod: cannot set permissions of 'cdev': Function not implemented > > Она как решаться, в этом случае, должна? Видимо таскать за собой свою libc, куда не дотянутся господа Левин и Малиновский. 229305 27 rider 2023-07-10 08:47:53 +0300 Проблема несовместимости альтовой glibc с окружающим миром не нова, но в данном случае, видимо (судя по сообщению про принтер) она имеет важное значение для совместимости с внешним софтом. Было бы неплохо уменьшить слой несовместимости, это в целом пойдёт нашему проекту на пользу. Ровно такая же история была тут: https://git.altlinux.org/gears/b/bubblewrap.git?p=bubblewrap.git;a=blob;f=bubblewrap-fix-run-path.patch;h=714285b163f95c85afb4774aef2e382c35929d07;hb=fa746ec340efac572ce6fe7b9013a602522540e7 но она решилась простым патчем, который обходит принятое в нашем glibc поведение (ломающее функционал внешнего приложения). В данном случае очевидно что это не так и внешнее приложение может расчитывать на апстримное поведение glibc. 229313 28 sin 2023-07-10 09:47:23 +0300 Иметь возможность принимать непопулярные технические решения - это ключевое свойство независимого репозитория. Я всегда за это ценил именно ALT. Но я пока так и не понял: "А в чем техническая необходимость данной несовместимости?" Плюс также вопррсы: А команда # mknod -m 666 cdev c 1 3 после всех исправлений работать у нас будет или не будет? Какие рекомендации и комментарии есть у нас в связи с этим для сторонних разработчиков? Ну, то есть "в связи с тем-то и тем-то", мы предлагаем поступать "так-то и так-то". По какой причине на разных архитектурах не смогли воспользоваться такими рекомендациями, а вынуждены был ажно попытку нового системного вызова в ядро организовать? По какой причине это исправление не было принято? По какой причине в портах вынуждены были откатить поведение glibc? 229318 29 asheplyakov 2023-07-10 10:18:54 +0300 (Ответ для Dmitry V. Levin на комментарий #24) > Продолжаем ликбез. А впрочем, я покажу Вам, что такое настоящий ликбез. Если Вы по какой-то причине не хотите, чтобы в coreutils НЕ использовалась реализация lchmod из glibc, то Вы добавляете в секцию %build перед вызовом %configure export ac_cv_func_lchmod=no Либо так: cat > config.cache <<EOF ac_cv_func_lchmod=no EOF %configure --cache-file=config.cache --blah --blah --blah А выпиливать lchmod из glibc не надо. 229319 30 asheplyakov 2023-07-10 10:20:22 +0300 (Ответ для Alexey Sheplyakov на комментарий #29) > (Ответ для Dmitry V. Levin на комментарий #24) > > Продолжаем ликбез. > > А впрочем, я покажу Вам, что такое настоящий ликбез. > > Если Вы по какой-то причине не хотите, чтобы в coreutils НЕ использовалась Следует читать "Если Вы хотите, чтобы в coreutils НЕ использовалась реализация lchmod" > реализация lchmod из glibc, то Вы добавляете в секцию %build перед вызовом > %configure > > export ac_cv_func_lchmod=no > > Либо так: > > cat > config.cache <<EOF > ac_cv_func_lchmod=no > EOF > > %configure --cache-file=config.cache --blah --blah --blah > > А выпиливать lchmod из glibc не надо. 229326 31 aris 2023-07-10 10:51:44 +0300 (Ответ для Anton Farygin на комментарий #27) > Было бы неплохо уменьшить слой несовместимости, это в целом пойдёт нашему > проекту на пользу. > > Ровно такая же история была тут: > https://git.altlinux.org/gears/b/bubblewrap.git?p=bubblewrap.git;a=blob; > f=bubblewrap-fix-run-path.patch;h=714285b163f95c85afb4774aef2e382c35929d07; > hb=fa746ec340efac572ce6fe7b9013a602522540e7 > > но она решилась простым патчем, который обходит принятое в нашем glibc > поведение (ломающее функционал внешнего приложения). Вероятно, это не единственная несовместимость. https://bugzilla.altlinux.org/46690 229327 32 sin 2023-07-10 10:54:35 +0300 Ну, то есть, с точки зрения апстрима, если функция lchmod не может быть реализована без /proc, то такая функция не должна предоставлять glibc. И мы решили, что будем строго следовать этому видению. Вот такое вот требование. При этом, поправьте меня, другие дистрибутивные решения, откатили у себя это требование апстрима. В итоге, каждое приложение, которое-таки использует этот lchmod должно решать эту проблему самостоятельно. Однако странно, что эта проблема вылезает именно на новых аппаратных платформах и выглядит более критичной, чем на x86_64. Кстати, а как обстоят дела для aarch64? Или оно везде так? Если да, то почему для RiscV это оказалось критично, а для aarch64 и x86_64 - нет? При этом все, как бы, можно решить, если в ядре появится-таки нужный системный вызов. Но сроки этого туманны и неопределенны. И мы вынуждены жить и патчить все, что требует этот злосчастный lchmod в glibc. На мой взгляд, данное техническое решение для дистрибутивных решений общего назначения выглядит преждевременным. А предложение "вернуть все взад" выглядит запоздалым. Актуализировалось всё это благодаря портированию. С этого и была начата данная бага. И вот тут я пока не понял какие технические предложения имеются. Рассмотрим то, что понятно: 1. Оставить в догоняющих сборках glibc с lchmod. Это состояние де-факто. 2. Пропатчить то, что не собирается без lchmod на новых аппаратных платформах. Причем сразу для всех платформ. 3. Дожидаться пока я ядре не появится новых системный вызов, далее пока не появится эта поддержка в glibc. И все это не будет пересобрано. Последний вариант звучит настолько чудесно и по срокам настолько не определенно, что я не вижу смысла рассматривать его в этой задаче, поскольку в этом случае непонятно что предлагается делать сейчас. С другой стороны. А что ломается-то? Принтеры некоторые ломаются, mknod что-то уметь перестает. Будем это все переписывать, чтобы следовать линии апстрима? Это не критично или что? Или как? 229330 33 rider 2023-07-10 10:59:06 +0300 (Ответ для Evgeny Sinelnikov на комментарий #28) > Иметь возможность принимать непопулярные технические решения - это ключевое > свойство независимого репозитория. Я всегда за это ценил именно ALT. > Непопулярные технические решение не должны ломать совместимость с окружающим миром. Когда весь мир ожидает от нашего окружения одного поведения, а мы предоставляем другое - то нужно или иметь галочку "режим совместимости" или с большей осторожностью делать такие изменения. 229341 34 sin 2023-07-10 11:38:02 +0300 Ну, хорошее пожелание. Пока не реализован соответствующий syscall в ядре, на других (каких?) аппаратных платформах полноценное повеление lchmod реализовать невозможно. И мы, впереди планеты всей, зафиксировали это на уровне abi в glibc. Теперь, если для x86_64, какие-то обходные пути имеются, то у нас для все платформ предложено это оторвать. И оторвано. Далее при портировании это вызывает такие сложности, что оторванное откатывают назад. И, в итоге, имеем два противоположных запроса: 1. ldv@, glebfm@ - верните все, как в Сизифе. 2. aheplyakov@ (+ rider@, aris@, но не столь категорично) - верните все назад, почините поломанную совместимость. Лично я предлагаю зафиксировать результат принятого решения. И, если несовместимость сохранится, документировать её на wiki. Следующим шагом можно ставить вопрос о пересмотре принятого решения. Кроме того, я спрашиваю, а почему для новых аппаратных платформ при портировании эта несовместимость оказалась столь критична? Как так вышло, что в одном случае эту несовместимость долго не замечали, а тут это оказалось так важно? Какой конкретно шаг блокируется из-за нее при портировании? Можно ли его обойти? Что для этого нужно сделать, если вариант "вернуть все назад" пока не рассматривать? Пока решение выглядит де-факто таким: - уже вернули назад для других архитектур; - сломать недолго, но можно уже не торопиться; - насколько я понял, в текущих реалиях, это что-то ломает, но можно "правильно" собрать. - собрать "правильно" все по одной схеме не получится - кроме рекомендаций для autotools, требуются рекомендации для все систем сборки. 229348 35 sin 2023-07-10 12:15:04 +0300 (Ответ для Dmitry V. Levin на комментарий #1) > К сожалению, fchmodat(..., AT_SYMLINK_NOFOLLOW) не реализовано в ядре: у > сисколла fchmodat вообще нет аргумента, через который можно было бы передать > флаги, а реализация в glibc использует /proc, в результате чего получается > https://sourceware.org/bugzilla/show_bug.cgi?id=26401 > > Так что баг не по адресу. > Реализуйте fchmodat4 в ядре, и будет всем счастье. Я так понимаю, что без нового сискола в ядре ничего "правильно" работать, все равно, не будет. Поэтому принято решение, что будем жить без "неправильного" варианта решения. Для всех есть одинаковая возможность это починить в каждом приложении, которое использует lchmod(). На x86_64 так сделано, на aarch64 сделано (я проверил). Предлагается исходную проблему решать аналогично. Почему? Потому что в glibc так решили ещё три года назад. Почему мы с этим сталкиваемся, а другие - нет. Потому что остальные (какие, кстати?) с этой проблемой не спешат. Какое решение? Пробросить нужный сискол в ядро... А как жить до этого? Ведь что получается на уровне API? Завтра, когда сискол-таки, может быть, пробросят все просто пересоберут свой код и ничего не заметят. Почему мы хотим это замечать? Потому что см. выше, на других платформах, это все равно вызывает неожиданное поведение. 229357 36 sin 2023-07-10 12:32:54 +0300 Да, неожиданное поведение возникает если не смонтирован /proc. Достойно ли ожидание "правильного" поведения выпиливания функции lchmod() из ABI в glibc. По мне так очень спорное решение. Что мешает сначала пробросить сискол в ядро, а потом это починить? Что мешает ревертнуть патч в апстримном glibc, чтобы избежать боли и несовместимости? Разное целеполагание. Сделать "правильно" или "чтобы работало"? Почему для "правильно" важно, чтобы в ядре появился сискол, которого там никогда не было? Почему на время пока он не проброшен необходимо менять ABI так, чтобы все были вынуждены линковаться с заглушкой? Что будет сделано, когда сискол появится, если весь смысл в этом? lchmod() вернут в ABI в glibc? Какой смысл тогда его было выпиливать? Что будет делать весь апстрим, если сискол не появится? 229358 37 ldv 2023-07-10 13:08:08 +0300 (In reply to Anton Farygin from comment #27) > Проблема несовместимости альтовой glibc с окружающим миром не нова, но в > данном случае, видимо (судя по сообщению про принтер) она имеет важное > значение для совместимости с внешним софтом. Судя по тому, что автор сообщения про принтер - это тот же самый чуть ли не единственный пользователь на планете, у которого не работает mknod, это сообщение нуждается в проверке. Просьба выяснить, что за принтер, что за софт, и повесить баг на тот софт, если он действительно не работает без lchmod. Ну и, конечно, большая просьба ко всем коллегам не замусоривать эту багу. 229359 38 ldv 2023-07-10 13:13:17 +0300 (In reply to Anton Farygin from comment #27) > Ровно такая же история была тут: > https://git.altlinux.org/gears/b/bubblewrap.git?p=bubblewrap.git;a=blob; > f=bubblewrap-fix-run-path.patch;h=714285b163f95c85afb4774aef2e382c35929d07; > hb=fa746ec340efac572ce6fe7b9013a602522540e7 Если тот код, который этот патч патчит, привилегированный, то этот патч создаёт уязвимость. Но это не имеет никакого отношения к lchmod. 229361 39 ldv 2023-07-10 13:15:37 +0300 (In reply to Yuri N. Sedunov from comment #31) > (Ответ для Anton Farygin на комментарий #27) > > Было бы неплохо уменьшить слой несовместимости, это в целом пойдёт нашему > > проекту на пользу. > > > > Ровно такая же история была тут: > > https://git.altlinux.org/gears/b/bubblewrap.git?p=bubblewrap.git;a=blob; > > f=bubblewrap-fix-run-path.patch;h=714285b163f95c85afb4774aef2e382c35929d07; > > hb=fa746ec340efac572ce6fe7b9013a602522540e7 > > > > но она решилась простым патчем, который обходит принятое в нашем glibc > > поведение (ломающее функционал внешнего приложения). > > Вероятно, это не единственная несовместимость. > https://bugzilla.altlinux.org/46690 Там вообще про ядро пишут. Не понимаю, почему все дружно решили превратить этот баг репорт в помойку. Давайте тогда закроем его и откроем новый, где не будет ничего, не относящегося к lchmod. 229364 40 rider 2023-07-10 13:25:40 +0300 Да просто много у кого наболело - хорошо когда несовместимость очевидна и явно видна, но вот как в случае с данной - несовместимость явно не проявляется и проблема больше выглядит как подземный стук. Такого быть не должно. Как и спорных утверждений о том, что у всех в glibc есть уязвимость. Если это действительно так, то наверное существуют общепринятые механизмы для публикации информации об уязвимостях. Если у bubblewrap есть уязвимость, то предлагаю её обсудить в отдельной ошибке. 229368 41 ldv 2023-07-10 13:33:38 +0300 (In reply to Evgeny Sinelnikov from comment #34) > Кроме того, я спрашиваю, а почему для новых аппаратных платформ при > портировании эта несовместимость оказалась столь критична? Непонятно, почему у тебя возникла такая иллюзия. Вопрос реализации lchmod не имеет совершенно никакого отношения к аппаратным архитектурам. Если бы тот метод бутстрапа, который был выбран для looongarch, был бы опробован на какой-нибудь ещё архитектуре, то проблема бы возникла и там. Это прямое следствие двух факторов: недостаточная версионированность lchmod, и недочёт протокола сборки пакетов во время бутстрапа. Грубо говоря, как только был собран альтовый тулчейн, все пакеты должны были быть пересобраны. 229369 42 sin 2023-07-10 13:38:42 +0300 Если основные игроки на ниве разработки стороннего софта используют дистрибутивные решения, где lchmod() в glibc сохранен, если мы рассчитываем, что после появления сискола эту функцию можно будет вернуть, то... получается, что все зависит от апстрима ядра. Плюс от последующих решений крупных игроков. Следуя в текущем состоянии требуется решить. Что делать с догоняющими аппаратными платформами? Оставляем, как есть, или вертаем. Последнее выглядит странно на фоне уже принятого решения много лет работающего Если так, то давайте это документируем и зафиксируем риски. Если документировать, то риски можно существенно снизить. А что будет, если сискол появится в ядре. У нас же тогда обратно lchmod() вернётся в ядро, или нет? Плюс ещё будет переход на новое ядро с новым glibc, где все, как у всех. Странная перспектива. 229370 43 sin 2023-07-10 13:39:58 +0300 (Ответ для Dmitry V. Levin на комментарий #41) > (In reply to Evgeny Sinelnikov from comment #34) > > Кроме того, я спрашиваю, а почему для новых аппаратных платформ при > > портировании эта несовместимость оказалась столь критична? > > Непонятно, почему у тебя возникла такая иллюзия. Иллюзия уже снята, я уже даже успел написать, что проверил. Вопросы перспективы меня смущают. 229371 44 sin 2023-07-10 13:43:01 +0300 Поправлюсь: А что будет, если сискол появится в ядре? У нас же тогда обратно lchmod() вернётся в glibc, или нет? Плюс ещё будет переход на новое ядро с новым glibc, где все, как у всех. Странная перспектива. 229522 45 ldv 2023-07-12 12:26:26 +0300 (In reply to Dmitry V. Levin from comment #1) > Реализуйте fchmodat4 в ядре, и будет всем счастье. Спасибо legion@, счастье всё-таки будет. :) В соответствии со сложившейся в последнее время традицией, cисколл получил модное имя fchmodat2. Ждём у Линуса в v6.6-rc1. 229549 46 sin 2023-07-12 14:25:48 +0300 То есть, после появления нового ядра, предположительно 6.6, мы можем ожидать возвращения в glibc функции lchmod? Можно ли ожидать, что этот получиться "провернуть" к концу лета, точнее до очередного бранчевания Сизифа? 229584 47 vt 2023-07-12 21:51:23 +0300 К концу лета даже 6.5 не выйдет, но это знают все кто здесь пишет, меня добавлять не обязательно. 257915 48 lav 2025-01-23 12:54:21 +0300 Спасибо за интересное обсуждение. Можно ли понимать ситуацию с lchmod, так, что что она является заглушкой в некоторых glibc (до 2.32), в glibc 2.32 и выше реализована только при доступности /proc, а работать везде станет при наличии ядра 6.6 и выше? Меня очень смущает ситуация, что приложения вообще не могут полагаться на то, что lchmod - это рабочая реализация. Если для обхода ситуации в приложениях будет добавлена собственная реализация lchmod, не будет ли это большим злом? Возникают вопросы к разработке glibc: Зачем было вообще добавлять lchmod как заглушку? Не лучше ли было, чтобы она вообще отсутствовала? Зачем было добавлять реализацию без версионирования? Было ли это ошибкой? Правильно ли я понимаю, что ещё достаточно функций, с которыми будут подобные приключения? $ cat /usr/include/gnu/stubs-64.h ... #define __stub___compat_bdflush #define __stub_chflags #define __stub_fchflags #define __stub_gtty #define __stub_lchmod #define __stub_revoke #define __stub_setlogin #define __stub_sigreturn #define __stub_stty