Bug 46816

Summary: glibc: lchmod is a stub -- несовместимость со сторонними приложениями
Product: Sisyphus Reporter: Alexey Sheplyakov <asheplyakov>
Component: glibcAssignee: placeholder <placeholder>
Status: NEW --- QA Contact: qa-sisyphus
Severity: major    
Priority: P5 CC: aris, asheplyakov, glebfm, iv, ldv, placeholder, rider, sin, vt
Version: unstable   
Hardware: all   
OS: Linux   

Description Alexey Sheplyakov 2023-07-08 12:34:01 MSK
# 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)
Comment 1 Dmitry V. Levin 2023-07-08 14:45:10 MSK
К сожалению, fchmodat(..., AT_SYMLINK_NOFOLLOW) не реализовано в ядре: у сисколла fchmodat вообще нет аргумента, через который можно было бы передать флаги, а реализация в glibc использует /proc, в результате чего получается https://sourceware.org/bugzilla/show_bug.cgi?id=26401

Так что баг не по адресу.
Реализуйте fchmodat4 в ядре, и будет всем счастье.
Comment 2 Dmitry V. Levin 2023-07-08 14:49:36 MSK
(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.
Comment 3 Gleb F-Malinovskiy 2023-07-08 14:55:38 MSK
(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, так что именно в этом случае стоит смотреть туда.
Comment 4 Alexey Sheplyakov 2023-07-08 17:01:06 MSK
(Ответ для 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.
Comment 5 Alexey Sheplyakov 2023-07-08 17:13:48 MSK
(Ответ для 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 проблему легче всего воспроизвести.
Comment 6 Gleb F-Malinovskiy 2023-07-08 17:37:39 MSK
А coreutils и остальные пострадавшие пакеты были собраны с каким-то неальтовым glibc?  Видимо, придётся пересобрать всё затронутое.
Comment 7 Evgeny Sinelnikov 2023-07-09 15:11:00 MSK
(Ответ для Gleb F-Malinovskiy на комментарий #6)
> А coreutils и остальные пострадавшие пакеты были собраны с каким-то
> неальтовым glibc?  Видимо, придётся пересобрать всё затронутое.

Сначала нужно решить проблему, которая возникала. Я так и не понял пока предложено л и решение.
Comment 8 Dmitry V. Levin 2023-07-09 15:25:43 MSK
(In reply to Evgeny Sinelnikov from comment #7)
> (Ответ для Gleb F-Malinovskiy на комментарий #6)
> > А coreutils и остальные пострадавшие пакеты были собраны с каким-то
> > неальтовым glibc?  Видимо, придётся пересобрать всё затронутое.
> 
> Сначала нужно решить проблему, которая возникала. Я так и не понял пока
> предложено л и решение.

У вас проблема, что вы собрали gnulib'ные пакеты с не-альтовой glibc, в результате они закладываются на семантику новой glibc'шной обёртки lchmod, которая не работает без /proc, и которой по этой причине в альтовой glibc нет.
По-видимому, для решения проблемы вам достаточно пересобрать gnulib'ные пакеты с альтовой glibc.
В любом, случае никакой looongarch'евой специфики тут не было и нет.
Comment 9 Dmitry V. Levin 2023-07-09 15:26:53 MSK
Кстати, кто-нибудь в курсе, какова судьба https://lore.kernel.org/lkml/20190717012719.5524-1-palmer@sifive.com/T/#mebf5710a5f551236940b9b5014f2b760ec8f8543
?
Comment 10 Evgeny Sinelnikov 2023-07-09 17:23:36 MSK
(Ответ для 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
Comment 11 Evgeny Sinelnikov 2023-07-09 17:38:01 MSK
(Ответ для 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, наконец-то озвучено.

Это совершенно неочевидное требование. Давайте его зафиксируем.

Также давайте определимся, что мы делаем пока не предложено технических решений для удовлетворения зафиксированному выше требованию? На текущий момент, предложение добавить в ядро новый системный вызов по какой-то причине не принято. Что мы можем с этим поделать?

Приостанавливать работу по портированию мы по этой причине, очевидно, не можем. Найти ресурс и заняться этой проблемой мы можем. Сроки решения этой проблемы измеряются месяцами и годами. Или я не прав?

Если изложенное выше не расходится с действительностью, то давайте говорить, что это "нас" всех одна и таже проблема, причём связанная с разными, новыми аппараратными платформами.

Когда мы её решим, всё, очевидно, придётся разок пересобрать.
Comment 12 Alexey Sheplyakov 2023-07-09 20:42:03 MSK
(Ответ для Gleb F-Malinovskiy на комментарий #6)
> А coreutils и остальные пострадавшие пакеты были собраны с каким-то
> неальтовым glibc?  Видимо, придётся пересобрать всё затронутое.

Сломана glibc, вот её и чинить надо - пересобрать без Вашего патча.
Comment 13 Alexey Sheplyakov 2023-07-09 20:52:16 MSK
(Ответ для 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'евой специфики тут не было и нет.

Тут согласен.
Comment 14 Alexey Sheplyakov 2023-07-09 20:56:44 MSK
Пересобрал glibc без этого патча на x86_64, и -- о чудо -- у меня заработал принтер hp laserjet p1102w. Раньше приходилось контейнер с Debian держать.
Видимо, где-то ему нужна рабочая lchmod
Comment 15 Alexey Sheplyakov 2023-07-09 21:01:59 MSK
(Ответ для Evgeny Sinelnikov на комментарий #11)

> Я бы поставил вопрос иначе. У нас всех эта проблема блокирует портирование
> лунгарча, в принципе. А решение, которое бы удовлетворило возможность
> запуска lchmod без /proc, отсутствует.
> 
> Я считаю, что эта проблема не должна и не может блокировать сам процесс
> портирования. Требование же, связанное с таким abi glibc, которое бы
> работало для lchmod без /proc, наконец-то озвучено.
> 
> Это совершенно неочевидное требование. Давайте его зафиксируем.

Возможность работы без /proc никем и ничем не гарантируется
(и это относится не только к glibc).

> Также давайте определимся, что мы делаем пока не предложено технических
> решений для удовлетворения зафиксированному выше требованию? На текущий
> момент, предложение добавить в ядро новый системный вызов по какой-то
> причине не принято. Что мы можем с этим поделать?
> 
> Приостанавливать работу по портированию мы по этой причине, очевидно, не
> можем. Найти ресурс и заняться этой проблемой мы можем. Сроки решения этой
> проблемы измеряются месяцами и годами. Или я не прав?
> 
> Если изложенное выше не расходится с действительностью, то давайте говорить,
> что это "нас" всех одна и таже проблема, причём связанная с разными, новыми
> аппараратными платформами.

Проблема не ограничена "новыми" платформами и проявляется на x86_64.

> Когда мы её решим, всё, очевидно, придётся разок пересобрать.

А сторонние приложения (доступные только в виде бинарных rpm) тоже пересобирать?
Или подгружать lchmod через LD_PRELOAD?
Comment 16 Dmitry V. Levin 2023-07-09 21:49:12 MSK
Давайте я расскажу очевидные вещи, которые, видимо, не все понимают.

Реализация lchmod через /proc в glibc появилась в glibc-2.32 (3 года назад), до этого там была заглушка.
У новой реализации нет новой версии (считается, что это деталь реализации), поэтому приложение, слинкованное с новой реализацией lchmod, не может рассчитывать, что во время работы вместо lchmod не будет заглушки.
По этой причине сторонние приложения вообще не могут полагаться на то, что lchmod - это рабочая реализация, а не заглушка, и так будет до тех пор, пока у новой реализации не появится версионирование.
На практике, к сожалению, были приложения, которые считали, что если во время сборки lchmod - это не заглушка, то и во время работы lchmod не будет заглушкой.  Вероятно, такие приложения есть в Сизифе и сейчас.
Comment 17 Evgeny Sinelnikov 2023-07-09 22:38:05 MSK
Я думаю, что следует отличать и рассматривать отдельно:
- пересмотр ранее принятых технических решений (даже если они недокументированы или, вообще, относятся к особенностям развития апстрима);
и
- сохранение целостности всех портов ранее принятым решениям.

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

Хочу обратить внимание на то, что ранее предложенный к рассмотрению патч для ядра с добавлением 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 - это рабочая реализация, а не заглушка". Какие рекомендации для разработчика тут имеются? Почему мы не занялись тогда ретрансляцией этой проблемы и исправлением её для таких приложений в Сизифе?

Имеется ли техническая возможность их исправить без предварительных правок других системных компонент, вроде ядра?
Comment 18 Evgeny Sinelnikov 2023-07-09 22:46:47 MSK
Да, вопросы, которые я попытался сформулировать могут выглядеть очевидными. Но было бы неплохо, чтобы все в деталях разобрались о чем, в сущности, идёт речь. Я думаю, что смогу разобраться и сам, но это будет дольше.

А тема-то уже мохнатая:
https://unix.stackexchange.com/questions/224979/why-do-linux-posix-have-lchown-but-not-lchmod
Comment 19 Gleb F-Malinovskiy 2023-07-09 23:31:31 MSK
Проблема есть и она настоящая, но важно, что loongarch64 ничем не отличается от других архитектур, и там это ничего не блокирует, всего лишь нужно пересобрать несколько пакетов.
Comment 20 Evgeny Sinelnikov 2023-07-10 00:15:53 MSK
(Ответ для Gleb F-Malinovskiy на комментарий #19)
> Проблема есть и она настоящая, но важно, что loongarch64 ничем не отличается
> от других архитектур, и там это ничего не блокирует, всего лишь нужно
> пересобрать несколько пакетов.

А можно уточнить каких конкретно?
И, наверное, речь не о просто
Comment 21 Evgeny Sinelnikov 2023-07-10 00:17:51 MSK
Наверное, речь не о "просто пересобрать".

И вот эта исходная проблема:
# mknod -m 666 cdev c 1 3
mknod: cannot set permissions of 'cdev': Function not implemented

Она как решаться, в этом случае, должна?
Comment 22 Gleb F-Malinovskiy 2023-07-10 00:24:31 MSK
(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.
Comment 23 Dmitry V. Levin 2023-07-10 00:37:34 MSK
(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
Comment 24 Dmitry V. Levin 2023-07-10 00:49:35 MSK
Продолжаем ликбез.
Когда AC_CHECK_FUNC из GNU autoconf проверяет наличие функции, специально проверяются макросы, которые предоставляет /usr/include/gnu/stubs.h, для того, чтобы stub не считался за существующую функцию.
Comment 25 Alexey Sheplyakov 2023-07-10 07:14:21 MSK
(Ответ для 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?
Comment 26 Alexey Sheplyakov 2023-07-10 07:15:33 MSK
(Ответ для Evgeny Sinelnikov на комментарий #21)
> Наверное, речь не о "просто пересобрать".
> 
> И вот эта исходная проблема:
> # mknod -m 666 cdev c 1 3
> mknod: cannot set permissions of 'cdev': Function not implemented
> 
> Она как решаться, в этом случае, должна?

Видимо таскать за собой свою libc, куда не дотянутся господа Левин и Малиновский.
Comment 27 Anton Farygin 2023-07-10 08:47:53 MSK
Проблема несовместимости альтовой 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.
Comment 28 Evgeny Sinelnikov 2023-07-10 09:47:23 MSK
Иметь возможность принимать непопулярные технические решения - это ключевое свойство независимого репозитория. Я всегда за это ценил именно ALT.

Но я пока так и не понял: "А в чем техническая необходимость данной несовместимости?"

Плюс также вопррсы:

А команда 
# mknod -m 666 cdev c 1 3
после всех исправлений работать у нас будет или не будет?

Какие рекомендации и комментарии есть у нас в связи с этим для сторонних разработчиков? Ну, то есть "в связи с тем-то и тем-то", мы предлагаем поступать "так-то и так-то".

По какой причине на разных архитектурах не смогли воспользоваться такими рекомендациями, а вынуждены был ажно попытку нового системного вызова в ядро организовать? По какой причине это исправление не было принято? По какой причине в портах вынуждены были откатить поведение glibc?
Comment 29 Alexey Sheplyakov 2023-07-10 10:18:54 MSK
(Ответ для 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 не надо.
Comment 30 Alexey Sheplyakov 2023-07-10 10:20:22 MSK
(Ответ для 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 не надо.
Comment 31 Yuri N. Sedunov 2023-07-10 10:51:44 MSK
(Ответ для 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
Comment 32 Evgeny Sinelnikov 2023-07-10 10:54:35 MSK
Ну, то есть, с точки зрения апстрима, если функция lchmod не может быть реализована без /proc, то такая функция не должна предоставлять glibc. И мы решили, что будем строго следовать этому видению. Вот такое вот требование.

При этом, поправьте меня, другие дистрибутивные решения, откатили у себя это требование апстрима.

В итоге, каждое приложение, которое-таки использует этот lchmod должно решать эту проблему самостоятельно.

Однако странно, что эта проблема вылезает именно на новых аппаратных платформах и выглядит более критичной, чем на x86_64. Кстати, а как обстоят дела для aarch64? Или оно везде так? Если да, то почему для RiscV это оказалось критично, а для aarch64 и x86_64 - нет?

При этом все, как бы, можно решить, если в ядре появится-таки нужный системный вызов. Но сроки этого туманны и неопределенны. И мы вынуждены жить и патчить все, что требует этот злосчастный lchmod в glibc.

На мой взгляд, данное техническое решение для дистрибутивных решений общего назначения выглядит преждевременным. А предложение "вернуть все взад" выглядит запоздалым.

Актуализировалось всё это благодаря портированию. С этого и была начата данная бага. И вот тут я пока не понял какие технические предложения имеются.

Рассмотрим то, что понятно:
1. Оставить в догоняющих сборках glibc с lchmod. Это состояние де-факто.

2. Пропатчить то, что не собирается без lchmod на новых аппаратных платформах. Причем сразу для всех платформ. 

3. Дожидаться пока я ядре не появится новых системный вызов, далее пока не появится эта поддержка в glibc. И все это не будет пересобрано. 

Последний вариант звучит настолько чудесно и по срокам настолько не определенно, что я не вижу смысла рассматривать его в этой задаче, поскольку в этом случае непонятно что предлагается делать сейчас.

С другой стороны. А что ломается-то? Принтеры некоторые ломаются, mknod что-то уметь перестает. Будем это все переписывать, чтобы следовать линии апстрима? Это не критично или что? Или как?
Comment 33 Anton Farygin 2023-07-10 10:59:06 MSK
(Ответ для Evgeny Sinelnikov на комментарий #28)
> Иметь возможность принимать непопулярные технические решения - это ключевое
> свойство независимого репозитория. Я всегда за это ценил именно ALT.
> 

Непопулярные технические решение не должны ломать совместимость с окружающим миром. Когда весь мир ожидает от нашего окружения одного поведения, а мы предоставляем другое - то нужно или иметь галочку "режим совместимости" или с большей осторожностью делать такие изменения.
Comment 34 Evgeny Sinelnikov 2023-07-10 11:38:02 MSK
Ну, хорошее пожелание. Пока не реализован соответствующий syscall в ядре, на других (каких?) аппаратных платформах полноценное повеление lchmod реализовать невозможно.

И мы, впереди планеты всей, зафиксировали это на уровне abi в glibc.

Теперь, если для x86_64, какие-то обходные пути имеются, то у нас для все платформ предложено это оторвать. И оторвано.

Далее при портировании это вызывает такие сложности, что оторванное откатывают назад.

И, в итоге, имеем два противоположных запроса:
1. ldv@, glebfm@ - верните все, как в Сизифе.
2. aheplyakov@ (+ rider@, aris@, но не столь категорично) - верните все назад, почините поломанную совместимость.

Лично я предлагаю зафиксировать результат принятого решения. И, если несовместимость сохранится, документировать её на wiki. Следующим шагом можно ставить вопрос о пересмотре принятого решения.

Кроме того, я спрашиваю, а почему для новых аппаратных платформ при портировании эта несовместимость оказалась столь критична?

Как так вышло, что в одном случае эту несовместимость долго не замечали, а тут это оказалось так важно? Какой конкретно шаг блокируется из-за нее при портировании? Можно ли его обойти? Что для этого нужно сделать, если вариант "вернуть все назад" пока не рассматривать?

Пока решение выглядит де-факто таким:
- уже вернули назад для других архитектур;
- сломать недолго, но можно уже не торопиться;
- насколько я понял, в текущих реалиях, это что-то ломает, но можно "правильно" собрать.
- собрать "правильно" все по одной схеме не получится - кроме рекомендаций для autotools,  требуются рекомендации для все систем сборки.
Comment 35 Evgeny Sinelnikov 2023-07-10 12:15:04 MSK
(Ответ для 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? Завтра, когда сискол-таки, может быть, пробросят все просто пересоберут свой код и ничего не заметят.

Почему мы хотим это замечать? Потому что см. выше, на других платформах, это все равно вызывает неожиданное поведение.
Comment 36 Evgeny Sinelnikov 2023-07-10 12:32:54 MSK
Да, неожиданное поведение возникает если не смонтирован /proc. Достойно ли ожидание "правильного" поведения выпиливания функции lchmod() из ABI в glibc. По мне так очень спорное решение.

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

Разное целеполагание. Сделать "правильно" или "чтобы работало"? Почему для "правильно" важно, чтобы в ядре появился сискол, которого там никогда не было? Почему на время пока он не проброшен необходимо менять ABI так, чтобы все были вынуждены линковаться с заглушкой?

Что будет сделано, когда сискол появится, если весь смысл в этом? lchmod() вернут в ABI в glibc? Какой смысл тогда его было выпиливать?

Что будет делать весь апстрим, если сискол не появится?
Comment 37 Dmitry V. Levin 2023-07-10 13:08:08 MSK
(In reply to Anton Farygin from comment #27)
> Проблема несовместимости альтовой glibc с окружающим миром не нова, но в
> данном случае, видимо (судя по сообщению про принтер) она имеет важное
> значение для совместимости с внешним софтом.

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

Просьба выяснить, что за принтер, что за софт, и повесить баг на тот софт, если он действительно не работает без lchmod.

Ну и, конечно, большая просьба ко всем коллегам не замусоривать эту багу.
Comment 38 Dmitry V. Levin 2023-07-10 13:13:17 MSK
(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.
Comment 39 Dmitry V. Levin 2023-07-10 13:15:37 MSK
(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.
Comment 40 Anton Farygin 2023-07-10 13:25:40 MSK
Да просто много у кого наболело - хорошо когда несовместимость очевидна и явно видна, но вот как в случае с данной - несовместимость явно не проявляется и проблема больше выглядит как подземный стук. Такого быть не должно.

Как и спорных утверждений о том, что у всех в glibc есть уязвимость. Если это действительно так, то наверное существуют общепринятые механизмы для публикации информации об уязвимостях.

Если у bubblewrap есть уязвимость, то предлагаю её обсудить в отдельной ошибке.
Comment 41 Dmitry V. Levin 2023-07-10 13:33:38 MSK
(In reply to Evgeny Sinelnikov from comment #34)
> Кроме того, я спрашиваю, а почему для новых аппаратных платформ при
> портировании эта несовместимость оказалась столь критична?

Непонятно, почему у тебя возникла такая иллюзия.  Вопрос реализации lchmod не имеет совершенно никакого отношения к аппаратным архитектурам.  Если бы тот метод бутстрапа, который был выбран для looongarch, был бы опробован на какой-нибудь ещё архитектуре, то проблема бы возникла и там.  Это прямое следствие двух факторов: недостаточная версионированность lchmod, и недочёт протокола сборки пакетов во время бутстрапа.
Грубо говоря, как только был собран альтовый тулчейн, все пакеты должны были быть пересобраны.
Comment 42 Evgeny Sinelnikov 2023-07-10 13:38:42 MSK
Если основные игроки на ниве разработки стороннего софта используют дистрибутивные решения, где lchmod() в glibc сохранен, если мы рассчитываем, что после появления сискола эту функцию можно будет вернуть, то... получается, что все зависит от апстрима ядра. 

Плюс от последующих решений крупных игроков.

Следуя в текущем состоянии требуется решить. Что делать с догоняющими аппаратными платформами? Оставляем, как есть, или вертаем. Последнее выглядит странно на фоне уже принятого решения много лет работающего 

Если так, то давайте это документируем и зафиксируем риски. Если документировать, то риски можно существенно снизить.

А что будет, если сискол появится в ядре. У нас же тогда обратно lchmod() вернётся в ядро, или нет? Плюс ещё будет переход на новое ядро с новым glibc, где все, как у всех. Странная перспектива.
Comment 43 Evgeny Sinelnikov 2023-07-10 13:39:58 MSK
(Ответ для Dmitry V. Levin на комментарий #41)
> (In reply to Evgeny Sinelnikov from comment #34)
> > Кроме того, я спрашиваю, а почему для новых аппаратных платформ при
> > портировании эта несовместимость оказалась столь критична?
> 
> Непонятно, почему у тебя возникла такая иллюзия.

Иллюзия уже снята, я уже даже успел написать, что проверил.

Вопросы перспективы меня смущают.
Comment 44 Evgeny Sinelnikov 2023-07-10 13:43:01 MSK
Поправлюсь:

А что будет, если сискол появится в ядре? У нас же тогда обратно lchmod() вернётся в glibc, или нет? Плюс ещё будет переход на новое ядро с новым glibc, где все, как у всех. Странная перспектива.
Comment 45 Dmitry V. Levin 2023-07-12 12:26:26 MSK
(In reply to Dmitry V. Levin from comment #1)
> Реализуйте fchmodat4 в ядре, и будет всем счастье.

Спасибо legion@, счастье всё-таки будет. :)
В соответствии со сложившейся в последнее время традицией, cисколл получил модное имя fchmodat2.  Ждём у Линуса в v6.6-rc1.
Comment 46 Evgeny Sinelnikov 2023-07-12 14:25:48 MSK
То есть, после появления нового ядра, предположительно 6.6, мы можем ожидать возвращения в glibc функции lchmod?

Можно ли ожидать, что этот получиться "провернуть" к концу лета, точнее до очередного бранчевания Сизифа?
Comment 47 Vitaly Chikunov 2023-07-12 21:51:23 MSK
К концу лета даже 6.5 не выйдет, но это знают все кто здесь пишет, меня добавлять не обязательно.