В стандартной Си-библиотеке Glibc выявлена уязвимость (CVE-2025-4802), позволяющая добиться выполнения кода с привилегиями другого пользователя, выставляемыми при запуске приложений с флагом suid. Опасность проблемы сводят на нет условия при которых она проявляется - разработчики Glibc на смогли найти не одной suid-программы к которой была бы применима найденная уязвимость. При этом не исключено, что в обиходе могут использоваться собственные suid-прогрммы, удовлетворяющие условиям совершения атаки...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63269
когда уже выпилят этот сломанный статический nss и dlopen? Он никогда не работает и только проблемы создаёт, Обычно бинарники собирают статически не чтобы из них dlopen делать.
Статический ffmpeg на дебиане вообще сегфолтится при попытке ресолвинга, очень полезно!!!
Можно пример, на каком моменте вы ловите segfault?
Это известный баг - когда nss от другой libc - такое блюдо надо уметь готовить.Но что странно - так то что ссылаются на
2017-12-19 Dmitry V. Levin <ldv@altlinux.org>
* elf/dl-load.c (is_trusted_path): Remove.
(fillin_rpath): Remove check_trusted argument and its use,
all callers changed.кто-то внес "оптимизацию" )))))
Левин небось за это повышение получил. Может даже старлея дали.
Так он её выпилил как раз потому, что она нигде не используется. Очень похоже, что кто-то с помощью нейросетки пытается поднять себе KPI, внося тормоза в нормальный код.
~$ /usr/lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Debian GLIBC 2.36-9+deb12u9) stable release version 2.36.
Запустить ffmpeg-7.0.2-amd64-static отсюда:
https://johnvansickle.com/ffmpeg/
и попытаться сделать любой сетевой запрос, как-то связанный с nss, например подать ссылку с любым доменом на вход приводит к сегфолту. На других версиях обычно был не сегфолт, а просто ресолвинг не работал.
Претензия в том, что в статический билд вообще попадает динамическая загрузка nss. Вместо этого должен быть либо стаб, либо фоллбэк, поддерживающий какую-то минимальную конфигурацию
это вопрос к сборщику ffmpeg, есть и libnss_*.aЯ решал эту проблему через chroot - но то был демон, ему было полезно. Не видит .so , то и не грузит.
возможно правка /etc/nsswitch.conf поможет.
Удивительно что для статической сборки кто-то использует glibc, разве это не киллер фичи компактных реализаций uclibc и musl.
В посте выше ссылка на сайт со статическими билдами и там зачем-то glibc (а помимо прочего ещё и x11 влинкован).
> когда уже выпилят этот сломанный статический nss и dlopen
> разработчики Glibc не смогли найти ни одной suid-программы, к которой была бы применима найденная уязвимостькогда начнут находить, тогда может кто и профинансирует выпиливание.
> затрагивающая статически собранные suid-файлы с dlopenА теперь коронный номер - поза "фантомас в очках на аэроплане".
Скорее уж "Товарищ милиционер, а вот если залезть на шкаф и воооот така вооооот выгнуть восьмёркой шею, то можно увидеть в бинокль голых девок в бане на том конце улицы! Примите меры!".
лучше бы запретили бы статическую сборку и не е***и бы мозги
зачем, когда можно её починить, а не пихать туда сомнительные вещи?
Статическая сборка хороша тем, что приложение использует меньше физической памяти и работает быстрее. Каждая .so независимо от реального размера загружаемого содержимого требует, минимум, три собственных страницы физической памяти, а статическая ровно столько, сколько занимает сама библиотека. Первый вызов функции из .so требует некоторого дополнительного времени на некотороые системные действия, что особенно заметно в интерактивных приложениях, котороые во время инициализации интерфейса выполняют десятки вызовов. Выглядит это как тормоза и достигают эти тормоза нескольких секунд.
> приложение использует меньше физической памятиНе неси чушь. SO либы в юнискосых системах расшарены, т.е. библиотека загружается ровно один раз даже если ее использует 100 программ.
В отличие от статической линковки, лол.
> некоторого дополнительного времени
> некотороые системные действияА, сори, у нас тут эксперт в треде. Чему я удивляюсь...
> библиотека загружается ровно один раз даже если ее использует 100 программ.Зато с статической линковкой работает LTO. А с шареными либами - нет.
Нужно ли lto или лучше пару мегабайт сэкономить - каждый решает сам.
> Зато с статической линковкой работает LTO. А с шареными либами - нет.Ну как бы логично, нет? На то они и шареные.
> Ну как бы логично, нет? На то они и шареные.Конечно логично, я же об этом и написал.
Но то, что оно не пашет это недостаток этого самого шаренья. Просто все так расписывают преимущества shared libs, как будто у них нет недостатков.А вот мне не жалко небольшого увеличения размера аппы ради небольшого увеличения производительности.
Если логика вашей программы настолько сильно упирается в скорость вызова какой-то функции из другой библиотеки, а не в IO, например, то либо статично компилируйтесь с этой библиотекой, либо чините компиляцию / меняйте компилятор.
>Если логика вашей программы настолько сильно упирается в скорость вызова какой-то функции из другой библиотеки, а не в IO, например, то либо статично компилируйтесь с этой библиотекойТак не пойдёт. Байты всё равно надо откуда-то прочитать. Количество байт от метода линковки зависит слабо, и условный бинарник на 100 Мб всё равно не будет прочитан мгновенно, по сравнению с динамически слинкованным
Ничего вы по памяти не сэкономите. Загруженная ранее .so будет отображена полностью в ваше адресное пространство, даже если вы из нее используете маленькую функцию. Это в отношени кода. Плюс у вас будет отображение секций инициализированных данных и неинициализированных, даже если функция, которую вы вызываете, их не использует. Именно поэтому вместе с .so нормальные пакеты предоставляют .a, собранные из мелких объектных модулей, ни на какие другие не ссылающиеся. Это для тех, кто понимает, что такое динамическое связывание и чем оно отличается от статического.
Я пишу, в основном, математику и если заказчик не возражает, использую gsl, которую сам компилирую и собираю как в .so, так и в .a, так что разницу в призводительности и в отношении свободной памяти в куче (malloc) чувствую непосредственно.
> Зато с статической линковкой работает LTO. А с шареными либами - нет.
> Нужно ли lto или лучше пару мегабайт сэкономить - каждый решает сам.Как бы тебе сказать то? Вгрузить в RAM 10 инстансов кутей, допустим, никак не пару мегабайт экономии будет. Вот 200 мегов RAM - это еще может быть.
> Статическая сборка хороша тем, что приложение использует меньше физической памяти и работает быстрее.Извиняюсь, но как раз динамическая сборка нужна, чтобы динамический линковщик при открытии библиотеки взял уже загруженный в shared памяти файл библиотеки.
>> Статическая сборка хороша тем, что приложение использует меньше физической памяти и работает быстрее.
> Извиняюсь, но как раз динамическая сборка нужна, чтобы динамический линковщик при открытии
> библиотеки взял уже загруженный в shared памяти файл библиотеки.Динамическая сборка годится только тогда, когда общая библиотека используется несколькими программами и в этом случае память, возможно, экономится. Кто-то первый загрузил и остальные уже используют загруженное, отображая библиотеку в свое адресное пространство.
"Единоличное" же использование общих библиотек одним приложением не имеет особого смысла, поскольку кроме этого приложения никакое другое этими библиотеками пользоваться не может и этому приложению в любом случае придется всякий раз их загружать и привязывать.
Статическая сборка хороша как минимум тем, что приложение будет более-менее гарантированно работать, вот это её главный плюс. Идея разделяемых библиотек в линуксе с треском провалилась, в винде оно как-то криво-косо, но работает.
> Идея разделяемых библиотек в линуксе с треском провалилась"Но шмель об этом не знает и продолжает летать..."
Да, до момента появления сообщения «у вас .so версии 2.11, а нужно 2.10» (или наоборот). Снапы с флатпаками от хорошей жизни выросли, видимо?
В Линуксе без проблем поставить рядом 2.10 и 2.11, без хелла.
Во-первых, и с хелпом проблема. Во-вторых, уже в этот момент концепция разделяемых библиотек похерена.
Только в nixos и guix sd. Во всех остальных случаях начинаются танцы с контейнерами, и прочим и прочим
Спешу вас расстроить, достаточно компилировать програмы с более точной версией библиотеки, которая вам нужна, а не "о, новая фича в 2.16, но всё равно буду линковаться с libcrap-2.so". Ничто не мешает положить в систему обе версии файла. На крайняк можно через переменные окружения в другую папку настроить (если бинарь нет возможности перекомпилировать правильно), либо и правда другой mount namespace сделать, если и так хотите заизолировать что-то.
О титан, не слишком ли тяжёл небосвод, не устал ли его держать?Согласен, что сделать можно, только мало кто делает. Тот же appimage у меня из коробки не запустился, так как какой-то библиотеки у меня не оказалось. Хотя казалось бы
> На крайняк можно через переменные окружения в другую папку настроитьИ насколько хорошо это работает мы можем посмотреть в том числе и по сабжевой новости. И нет, проблемы танцевать красиво с «другими папками», неймспейсами, небом и аллахом нет. Проблема есть в том, что эти танцы надоели ещё пятнадцать лет тому назад, если не все двадцать, и судя по набирающим популярность флатпакам, аппимиджам и снапу — не только мне одному.
Пакетные менеджеры мешают т.к не умеют ставить одновременно 2 разных минорных весрии.
В gentoo это кое-как решается preserved-libs, но он используется только в случае обновления библиотеки на более новую. Рач же сносит старую библиотеку при обновлении даже когда она используется, сводя всю ценность линковки к точной версии на нет
Снапы с флетпаками выросли сугубо от хорошей жизни менеджера, который ничего лучше не смог придумать.
Впрочем, линковка к точной версии библиотеки не спасёт от конфликта символов внутри процесса.
Если в windows линковка происходит к dllname.dll:funcname, то в линуксах просто к funcname или в лучшем случае к funcname:SYMVER... что не исключает возможности как одинаковых funcname, так и одинаковых funcname:SYMVER в разных процессах...
> "Но шмель об этом не знает и продолжает летать..."Да-да, особенно когда на каком-то копродистре вроде деба тебе срочно нужно обновить что-то чтобы исправить бесячий баг или дыру, а дебилианцы не считают это проблемой.
И вот тогда начинается веселье.
и там гарантированно не будет работать ресолвинг
> Статическая сборка хороша как минимум тем, что приложение будет более-менее гарантированно
> работать, вот это её главный плюс. Идея разделяемых библиотек в линуксе
> с треском провалилась, в винде оно как-то криво-косо, но работает.В никсах нет "разделяемых" библиотек, но есть совместно используемые объекты (shared object), которые иногда называются "общие библиотеки".
>Выглядит это как тормоза и достигают эти тормоза нескольких секундЭм, а какого года выпуска у вас железо?
>что особенно заметно в интерактивных приложенияхИнтерактивные приложения постоянно что-то вызывают. Очень маловероятно, что приложение с нуля загрузится в память целиком, со всеми иконками библиотеками и прочим
>котороые во время инициализации интерфейса выполняют десятки вызововПочему десятки? Вот смотрите, типовой современный сайт на php вызывает тысячи, может даже десятки тысяч файлов на один запрос. И вы всех этих тысяч файлов не увидите, для вас это займёт ну может сотню милисекунд. Так почему десктопные приложения у вас тогда тормозят несколько секунд?
Человек наверное под виндой сидит, где кэш файловой системы по ощущениям постоянно выключен.
>[оверквотинг удален]
> Эм, а какого года выпуска у вас железо?HP Zbook c 32 Гбайт ОЗУ и ПП-диском.
>>что особенно заметно в интерактивных приложениях
> Интерактивные приложения постоянно что-то вызывают. Очень маловероятно, что приложение
> с нуля загрузится в память целиком, со всеми иконками библиотеками и
> прочим
>>котороые во время инициализации интерфейса выполняют десятки вызовов
> Почему десятки? Вот смотрите, типовой современный сайт на php вызывает тысячи, может
> даже десятки тысяч файлов на один запрос.Сайт кеширует в памяти содержимое всех этих мелких файлов и выгружает их только тогда, когда нужно освободить физическую память под более насущные задачи. По крайней мере, кешируются все индексы, мелкие таблицы, типа LUT ("справочники") и все страницы баз данных, к которым были недавние обращения, если они "не мешают".
> И вы всех этих тысяч файлов не увидите, для вас это займёт ну может сотню
> милисекунд. Так почему десктопные приложения у вас тогда тормозят несколько секунд?Они у всех на старте (речь именно об этом, не так ли?) тормозят. Просто померяйте, сколько времени у вас загружается libreoffice writer с пустым файлом ($ libreoffice --writer) без предзагрузки .so и и с их предзагрузкой (второй запуск $ libreoffice --writer)? Вот разница и будет тем временем, которое требуется на загрузку и привязку всех требуемых .so. Второй запуск у меня занимает менее секунды в отличие от первого, который в зависимости от того, что в данный момент работает (например, maple считает, используя всю доступную память), может составлять до 20 секунд.
Также десктопные приложения, использующие динамическую сборку меню, панелей и прочих виджетов, всегда тормозят, поскольку процесс компиляции описания, сборка, инициализация, рендеринг файла отрисовки и отрисовка стартует не при загрузке приложения, а при первом обращении и занимает времени гораздо больше, чем просто отрисовка команд из готового файла, сформированного в случае статического интерфейса, и полностью подготовленного к работе в процессе связывания приложения.
Спасибо, для статической сборки уже нужен musl.
> лучше бы запретили бы статическую сборку и не е***и бы мозгиПодрабатываете в НСА ?