Re: [devel] __libc_enable_secure в openssl libcrypto

[Mikhail Novosyolov <mikhailnov@altlinux.org>]

18.04.2020 02:54, Dmitry V. Levin пишет:
> On Sat, Apr 18, 2020 at 02:21:43AM +0300, Mikhail Novosyolov wrote:
>> Попробовал собрать AppImage на основе библиотек из Альта. AppImage - это такая штука, где сбандлены необходимые для работы программы библиотеки, но libc используется системная, что позволяет и программу запускать в разных дистрибутивах, и системные плагины NSS использовать. Для этой цели собрал в сизиф пакет linuxdeployqt.
>>
>> Оказалось, что libcrypto.so.10 (я делал на основе p8, то же самое будет относиться и к сизифу) использует внутренний в glibc интерфейс __libc_enable_secure, который не выведен наружу в других дистрибутивах.
> Всё-таки __libc_enable_secure выведен у всех, потому что этот символ
> определён в ld, а используется ещё и в libc.  Но у нас этот символ
> версионирован не как у всех в GLIBC_PRIVATE, а в baseline version, что,
> наверное, было не совсем правильно сделано, лучше было бы выделить для
> этого отдельную версию, но потом уже поздно было это менять.
>
> У нас в libc есть ещё несколько символов, которые широко используются
> нашими пакетами, но которых пока нет в других libc:
> __strlcat_chk
> __strlcpy_chk
> strlcat
> strlcpy
>
>> Это сделано патчем openssl-owl-alt-issetugid.patch:
>>> --- openssl/crypto/uid.c
>>> +++ openssl/crypto/uid.c
>>> @@ -77,8 +77,12 @@ int OPENSSL_issetugid(void)
>>>  # include OPENSSL_UNISTD
>>>  # include <sys/types.h>
>>>  
>>> +extern int __libc_enable_secure;
>>> +
>>>  int OPENSSL_issetugid(void)
>>>  {
>>> +    if (__libc_enable_secure)
>>> +        return 1;
>>>      if (getuid() != geteuid())
>>>          return 1;
>>>      if (getgid() != getegid())
>> В связи с этим возник вопрос: в Альте glibc запатчен, чтобы вывести эту внутреннюю функцию?
> Да, коммит 730399f767758a200256d7eb20f74d2310ab973b.
>
>> Используется ли она в каких-либо еще внешних потребителях?
> Как минимум ещё в libtinfo.

У меня получилось собрать работающую на других дистрибутивах AppImage-подобную структуру на основе библиотек из p8, в т.ч. Qt5 оттуда, путем сборки openssl без патча openssl-owl-alt-issetugid.patch. Но наличие таких нюансов стало неприятной неожиданностью, и вот почему.

Начнем с "обычных" пользователей. Среди них достаточно востребовано иметь возможность запускать AppImage и другие сторонние бинарные сборки в целях упрощения жизни и решения повседневных задач. Но вроде бы они особо не страдают и могут их запускать (ну, кроме заблокированного из коробки fuse, что мешает запустить AppImage, но, с точки зрения администратора корпоративных рабочих станций, мне такая блокировка из коробки скорее нравится, чем не нравится).

Больше всего интересует вопрос отечественной блобятинки, т.е. различных программных изделий, выпускаемых и используемых в рамках импортозамещения. Большинство их разработчиков не очень хорошо умеют упаковывать программы под Линукс, как с точки зрения сборки исполняемых файлов, так и с точки зрения создания RPM-пакетов или иных форм дистрибуции. В результате некоторые из них поддерживают только 1-2 отечественных дистрибутива, теряя часть пользователей, некоторые пытаются собирать по пакету под каждый дистрибутив, тратя на это огромное количество ресурсов. Это плохо и для разработчиков ПО, и для разработчиков дистрибутивов, которые вынуждены иметь с ним дело. Единственным выходом из ситуации я вижу попытки рекомендовать разработчикам собирать универсальные исполняемые файлы или пакеты с грамотно сбандленными библиотеками и грамотно прописанные зависимости в RPM, например, не libgnomekeyring, a libgnome-keyring.so.0()(64bit). Была мысль, что многим будет гораздо проще не
изобретать сложную систему сборки с частичной статической линковкой, а собирать с системными библиотеками в какой-нибудь ОС, а затем упаковывать AppImage, это очень просто. AppImage-подобную структуру можно положить в RPM-пакет, зная про AutoReq, AutoProv и др. И вот здесь встает вопрос, насколько помешают такие фокусы. Соберут в Альте - не заработает в других дистрибутивах. Тот же openssl настолько часто используется и однозначно будет сбандливаться, что Альт можно сразу не рекомендовать для сборки AppImage-подобных пакетов. А вот если собрать ПО на другом дистрибутиве, то есть небольшая вероятность возникновения проблем в Альте. Думаю, что нужно сильно постараться, чтобы их поймать, т.к. внутренний API __libc_enable_secure заведомо не стоит использовать, но, может быть, есть другие подобные нюансы.