# 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)
К сожалению, fchmodat(..., AT_SYMLINK_NOFOLLOW) не реализовано в ядре: у сисколла fchmodat вообще нет аргумента, через который можно было бы передать флаги, а реализация в glibc использует /proc, в результате чего получается https://sourceware.org/bugzilla/show_bug.cgi?id=26401 Так что баг не по адресу. Реализуйте fchmodat4 в ядре, и будет всем счастье.
(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.
(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, так что именно в этом случае стоит смотреть туда.
(Ответ для 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.
(Ответ для 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 проблему легче всего воспроизвести.
А coreutils и остальные пострадавшие пакеты были собраны с каким-то неальтовым glibc? Видимо, придётся пересобрать всё затронутое.
(Ответ для Gleb F-Malinovskiy на комментарий #6) > А coreutils и остальные пострадавшие пакеты были собраны с каким-то > неальтовым glibc? Видимо, придётся пересобрать всё затронутое. Сначала нужно решить проблему, которая возникала. Я так и не понял пока предложено л и решение.
(In reply to Evgeny Sinelnikov from comment #7) > (Ответ для Gleb F-Malinovskiy на комментарий #6) > > А coreutils и остальные пострадавшие пакеты были собраны с каким-то > > неальтовым glibc? Видимо, придётся пересобрать всё затронутое. > > Сначала нужно решить проблему, которая возникала. Я так и не понял пока > предложено л и решение. У вас проблема, что вы собрали gnulib'ные пакеты с не-альтовой glibc, в результате они закладываются на семантику новой glibc'шной обёртки lchmod, которая не работает без /proc, и которой по этой причине в альтовой glibc нет. По-видимому, для решения проблемы вам достаточно пересобрать gnulib'ные пакеты с альтовой glibc. В любом, случае никакой looongarch'евой специфики тут не было и нет.
Кстати, кто-нибудь в курсе, какова судьба https://lore.kernel.org/lkml/20190717012719.5524-1-palmer@sifive.com/T/#mebf5710a5f551236940b9b5014f2b760ec8f8543 ?
(Ответ для 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
(Ответ для 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, наконец-то озвучено. Это совершенно неочевидное требование. Давайте его зафиксируем. Также давайте определимся, что мы делаем пока не предложено технических решений для удовлетворения зафиксированному выше требованию? На текущий момент, предложение добавить в ядро новый системный вызов по какой-то причине не принято. Что мы можем с этим поделать? Приостанавливать работу по портированию мы по этой причине, очевидно, не можем. Найти ресурс и заняться этой проблемой мы можем. Сроки решения этой проблемы измеряются месяцами и годами. Или я не прав? Если изложенное выше не расходится с действительностью, то давайте говорить, что это "нас" всех одна и таже проблема, причём связанная с разными, новыми аппараратными платформами. Когда мы её решим, всё, очевидно, придётся разок пересобрать.
(Ответ для Gleb F-Malinovskiy на комментарий #6) > А coreutils и остальные пострадавшие пакеты были собраны с каким-то > неальтовым glibc? Видимо, придётся пересобрать всё затронутое. Сломана glibc, вот её и чинить надо - пересобрать без Вашего патча.
(Ответ для 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'евой специфики тут не было и нет. Тут согласен.
Пересобрал glibc без этого патча на x86_64, и -- о чудо -- у меня заработал принтер hp laserjet p1102w. Раньше приходилось контейнер с Debian держать. Видимо, где-то ему нужна рабочая lchmod
(Ответ для Evgeny Sinelnikov на комментарий #11) > Я бы поставил вопрос иначе. У нас всех эта проблема блокирует портирование > лунгарча, в принципе. А решение, которое бы удовлетворило возможность > запуска lchmod без /proc, отсутствует. > > Я считаю, что эта проблема не должна и не может блокировать сам процесс > портирования. Требование же, связанное с таким abi glibc, которое бы > работало для lchmod без /proc, наконец-то озвучено. > > Это совершенно неочевидное требование. Давайте его зафиксируем. Возможность работы без /proc никем и ничем не гарантируется (и это относится не только к glibc). > Также давайте определимся, что мы делаем пока не предложено технических > решений для удовлетворения зафиксированному выше требованию? На текущий > момент, предложение добавить в ядро новый системный вызов по какой-то > причине не принято. Что мы можем с этим поделать? > > Приостанавливать работу по портированию мы по этой причине, очевидно, не > можем. Найти ресурс и заняться этой проблемой мы можем. Сроки решения этой > проблемы измеряются месяцами и годами. Или я не прав? > > Если изложенное выше не расходится с действительностью, то давайте говорить, > что это "нас" всех одна и таже проблема, причём связанная с разными, новыми > аппараратными платформами. Проблема не ограничена "новыми" платформами и проявляется на x86_64. > Когда мы её решим, всё, очевидно, придётся разок пересобрать. А сторонние приложения (доступные только в виде бинарных rpm) тоже пересобирать? Или подгружать lchmod через LD_PRELOAD?
Давайте я расскажу очевидные вещи, которые, видимо, не все понимают. Реализация lchmod через /proc в glibc появилась в glibc-2.32 (3 года назад), до этого там была заглушка. У новой реализации нет новой версии (считается, что это деталь реализации), поэтому приложение, слинкованное с новой реализацией lchmod, не может рассчитывать, что во время работы вместо lchmod не будет заглушки. По этой причине сторонние приложения вообще не могут полагаться на то, что lchmod - это рабочая реализация, а не заглушка, и так будет до тех пор, пока у новой реализации не появится версионирование. На практике, к сожалению, были приложения, которые считали, что если во время сборки lchmod - это не заглушка, то и во время работы lchmod не будет заглушкой. Вероятно, такие приложения есть в Сизифе и сейчас.
Я думаю, что следует отличать и рассматривать отдельно: - пересмотр ранее принятых технических решений (даже если они недокументированы или, вообще, относятся к особенностям развития апстрима); и - сохранение целостности всех портов ранее принятым решениям. Текущая задача, всё-таки рассматривается не как пересмотр ранее принятых решений, а как проблема связанная с блокированием работы над портами, работы над которыми не могут быть продолжены без отхода от требований по ранее принятым решениям. Хочу обратить внимание на то, что ранее предложенный к рассмотрению патч для ядра с добавлением 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 - это рабочая реализация, а не заглушка". Какие рекомендации для разработчика тут имеются? Почему мы не занялись тогда ретрансляцией этой проблемы и исправлением её для таких приложений в Сизифе? Имеется ли техническая возможность их исправить без предварительных правок других системных компонент, вроде ядра?
Да, вопросы, которые я попытался сформулировать могут выглядеть очевидными. Но было бы неплохо, чтобы все в деталях разобрались о чем, в сущности, идёт речь. Я думаю, что смогу разобраться и сам, но это будет дольше. А тема-то уже мохнатая: https://unix.stackexchange.com/questions/224979/why-do-linux-posix-have-lchown-but-not-lchmod
Проблема есть и она настоящая, но важно, что loongarch64 ничем не отличается от других архитектур, и там это ничего не блокирует, всего лишь нужно пересобрать несколько пакетов.
(Ответ для Gleb F-Malinovskiy на комментарий #19) > Проблема есть и она настоящая, но важно, что loongarch64 ничем не отличается > от других архитектур, и там это ничего не блокирует, всего лишь нужно > пересобрать несколько пакетов. А можно уточнить каких конкретно? И, наверное, речь не о просто
Наверное, речь не о "просто пересобрать". И вот эта исходная проблема: # mknod -m 666 cdev c 1 3 mknod: cannot set permissions of 'cdev': Function not implemented Она как решаться, в этом случае, должна?
(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.
(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
Продолжаем ликбез. Когда AC_CHECK_FUNC из GNU autoconf проверяет наличие функции, специально проверяются макросы, которые предоставляет /usr/include/gnu/stubs.h, для того, чтобы stub не считался за существующую функцию.
(Ответ для 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?
(Ответ для Evgeny Sinelnikov на комментарий #21) > Наверное, речь не о "просто пересобрать". > > И вот эта исходная проблема: > # mknod -m 666 cdev c 1 3 > mknod: cannot set permissions of 'cdev': Function not implemented > > Она как решаться, в этом случае, должна? Видимо таскать за собой свою libc, куда не дотянутся господа Левин и Малиновский.
Проблема несовместимости альтовой 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.
Иметь возможность принимать непопулярные технические решения - это ключевое свойство независимого репозитория. Я всегда за это ценил именно ALT. Но я пока так и не понял: "А в чем техническая необходимость данной несовместимости?" Плюс также вопррсы: А команда # mknod -m 666 cdev c 1 3 после всех исправлений работать у нас будет или не будет? Какие рекомендации и комментарии есть у нас в связи с этим для сторонних разработчиков? Ну, то есть "в связи с тем-то и тем-то", мы предлагаем поступать "так-то и так-то". По какой причине на разных архитектурах не смогли воспользоваться такими рекомендациями, а вынуждены был ажно попытку нового системного вызова в ядро организовать? По какой причине это исправление не было принято? По какой причине в портах вынуждены были откатить поведение glibc?
(Ответ для 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 не надо.
(Ответ для 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 не надо.
(Ответ для 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 не может быть реализована без /proc, то такая функция не должна предоставлять glibc. И мы решили, что будем строго следовать этому видению. Вот такое вот требование. При этом, поправьте меня, другие дистрибутивные решения, откатили у себя это требование апстрима. В итоге, каждое приложение, которое-таки использует этот lchmod должно решать эту проблему самостоятельно. Однако странно, что эта проблема вылезает именно на новых аппаратных платформах и выглядит более критичной, чем на x86_64. Кстати, а как обстоят дела для aarch64? Или оно везде так? Если да, то почему для RiscV это оказалось критично, а для aarch64 и x86_64 - нет? При этом все, как бы, можно решить, если в ядре появится-таки нужный системный вызов. Но сроки этого туманны и неопределенны. И мы вынуждены жить и патчить все, что требует этот злосчастный lchmod в glibc. На мой взгляд, данное техническое решение для дистрибутивных решений общего назначения выглядит преждевременным. А предложение "вернуть все взад" выглядит запоздалым. Актуализировалось всё это благодаря портированию. С этого и была начата данная бага. И вот тут я пока не понял какие технические предложения имеются. Рассмотрим то, что понятно: 1. Оставить в догоняющих сборках glibc с lchmod. Это состояние де-факто. 2. Пропатчить то, что не собирается без lchmod на новых аппаратных платформах. Причем сразу для всех платформ. 3. Дожидаться пока я ядре не появится новых системный вызов, далее пока не появится эта поддержка в glibc. И все это не будет пересобрано. Последний вариант звучит настолько чудесно и по срокам настолько не определенно, что я не вижу смысла рассматривать его в этой задаче, поскольку в этом случае непонятно что предлагается делать сейчас. С другой стороны. А что ломается-то? Принтеры некоторые ломаются, mknod что-то уметь перестает. Будем это все переписывать, чтобы следовать линии апстрима? Это не критично или что? Или как?
(Ответ для Evgeny Sinelnikov на комментарий #28) > Иметь возможность принимать непопулярные технические решения - это ключевое > свойство независимого репозитория. Я всегда за это ценил именно ALT. > Непопулярные технические решение не должны ломать совместимость с окружающим миром. Когда весь мир ожидает от нашего окружения одного поведения, а мы предоставляем другое - то нужно или иметь галочку "режим совместимости" или с большей осторожностью делать такие изменения.
Ну, хорошее пожелание. Пока не реализован соответствующий syscall в ядре, на других (каких?) аппаратных платформах полноценное повеление lchmod реализовать невозможно. И мы, впереди планеты всей, зафиксировали это на уровне abi в glibc. Теперь, если для x86_64, какие-то обходные пути имеются, то у нас для все платформ предложено это оторвать. И оторвано. Далее при портировании это вызывает такие сложности, что оторванное откатывают назад. И, в итоге, имеем два противоположных запроса: 1. ldv@, glebfm@ - верните все, как в Сизифе. 2. aheplyakov@ (+ rider@, aris@, но не столь категорично) - верните все назад, почините поломанную совместимость. Лично я предлагаю зафиксировать результат принятого решения. И, если несовместимость сохранится, документировать её на wiki. Следующим шагом можно ставить вопрос о пересмотре принятого решения. Кроме того, я спрашиваю, а почему для новых аппаратных платформ при портировании эта несовместимость оказалась столь критична? Как так вышло, что в одном случае эту несовместимость долго не замечали, а тут это оказалось так важно? Какой конкретно шаг блокируется из-за нее при портировании? Можно ли его обойти? Что для этого нужно сделать, если вариант "вернуть все назад" пока не рассматривать? Пока решение выглядит де-факто таким: - уже вернули назад для других архитектур; - сломать недолго, но можно уже не торопиться; - насколько я понял, в текущих реалиях, это что-то ломает, но можно "правильно" собрать. - собрать "правильно" все по одной схеме не получится - кроме рекомендаций для autotools, требуются рекомендации для все систем сборки.
(Ответ для 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? Завтра, когда сискол-таки, может быть, пробросят все просто пересоберут свой код и ничего не заметят. Почему мы хотим это замечать? Потому что см. выше, на других платформах, это все равно вызывает неожиданное поведение.
Да, неожиданное поведение возникает если не смонтирован /proc. Достойно ли ожидание "правильного" поведения выпиливания функции lchmod() из ABI в glibc. По мне так очень спорное решение. Что мешает сначала пробросить сискол в ядро, а потом это починить? Что мешает ревертнуть патч в апстримном glibc, чтобы избежать боли и несовместимости? Разное целеполагание. Сделать "правильно" или "чтобы работало"? Почему для "правильно" важно, чтобы в ядре появился сискол, которого там никогда не было? Почему на время пока он не проброшен необходимо менять ABI так, чтобы все были вынуждены линковаться с заглушкой? Что будет сделано, когда сискол появится, если весь смысл в этом? lchmod() вернут в ABI в glibc? Какой смысл тогда его было выпиливать? Что будет делать весь апстрим, если сискол не появится?
(In reply to Anton Farygin from comment #27) > Проблема несовместимости альтовой glibc с окружающим миром не нова, но в > данном случае, видимо (судя по сообщению про принтер) она имеет важное > значение для совместимости с внешним софтом. Судя по тому, что автор сообщения про принтер - это тот же самый чуть ли не единственный пользователь на планете, у которого не работает mknod, это сообщение нуждается в проверке. Просьба выяснить, что за принтер, что за софт, и повесить баг на тот софт, если он действительно не работает без lchmod. Ну и, конечно, большая просьба ко всем коллегам не замусоривать эту багу.
(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.
(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.
Да просто много у кого наболело - хорошо когда несовместимость очевидна и явно видна, но вот как в случае с данной - несовместимость явно не проявляется и проблема больше выглядит как подземный стук. Такого быть не должно. Как и спорных утверждений о том, что у всех в glibc есть уязвимость. Если это действительно так, то наверное существуют общепринятые механизмы для публикации информации об уязвимостях. Если у bubblewrap есть уязвимость, то предлагаю её обсудить в отдельной ошибке.
(In reply to Evgeny Sinelnikov from comment #34) > Кроме того, я спрашиваю, а почему для новых аппаратных платформ при > портировании эта несовместимость оказалась столь критична? Непонятно, почему у тебя возникла такая иллюзия. Вопрос реализации lchmod не имеет совершенно никакого отношения к аппаратным архитектурам. Если бы тот метод бутстрапа, который был выбран для looongarch, был бы опробован на какой-нибудь ещё архитектуре, то проблема бы возникла и там. Это прямое следствие двух факторов: недостаточная версионированность lchmod, и недочёт протокола сборки пакетов во время бутстрапа. Грубо говоря, как только был собран альтовый тулчейн, все пакеты должны были быть пересобраны.
Если основные игроки на ниве разработки стороннего софта используют дистрибутивные решения, где lchmod() в glibc сохранен, если мы рассчитываем, что после появления сискола эту функцию можно будет вернуть, то... получается, что все зависит от апстрима ядра. Плюс от последующих решений крупных игроков. Следуя в текущем состоянии требуется решить. Что делать с догоняющими аппаратными платформами? Оставляем, как есть, или вертаем. Последнее выглядит странно на фоне уже принятого решения много лет работающего Если так, то давайте это документируем и зафиксируем риски. Если документировать, то риски можно существенно снизить. А что будет, если сискол появится в ядре. У нас же тогда обратно lchmod() вернётся в ядро, или нет? Плюс ещё будет переход на новое ядро с новым glibc, где все, как у всех. Странная перспектива.
(Ответ для Dmitry V. Levin на комментарий #41) > (In reply to Evgeny Sinelnikov from comment #34) > > Кроме того, я спрашиваю, а почему для новых аппаратных платформ при > > портировании эта несовместимость оказалась столь критична? > > Непонятно, почему у тебя возникла такая иллюзия. Иллюзия уже снята, я уже даже успел написать, что проверил. Вопросы перспективы меня смущают.
Поправлюсь: А что будет, если сискол появится в ядре? У нас же тогда обратно lchmod() вернётся в glibc, или нет? Плюс ещё будет переход на новое ядро с новым glibc, где все, как у всех. Странная перспектива.
(In reply to Dmitry V. Levin from comment #1) > Реализуйте fchmodat4 в ядре, и будет всем счастье. Спасибо legion@, счастье всё-таки будет. :) В соответствии со сложившейся в последнее время традицией, cисколл получил модное имя fchmodat2. Ждём у Линуса в v6.6-rc1.
То есть, после появления нового ядра, предположительно 6.6, мы можем ожидать возвращения в glibc функции lchmod? Можно ли ожидать, что этот получиться "провернуть" к концу лета, точнее до очередного бранчевания Сизифа?
К концу лета даже 6.5 не выйдет, но это знают все кто здесь пишет, меня добавлять не обязательно.
