From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 18 Dec 2016 13:13:47 +0300 (MSK) From: Ivan Zakharyaschev To: ALT Linux Team development discussions In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1807885841-1890473363-1482056027=:1300" Subject: Re: [devel] I: verify-elf for plugins etc. with RPM_LD_PRELOAD_xxxx & RPM_FILES_TO_LD_PRELOAD_xxxx; was: Re: python3-3.5 unmets X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 10:13:48 -0000 Archived-At: List-Archive: List-Post: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1807885841-1890473363-1482056027=:1300 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Хочу дописать своё мнение о том, хороший это механизм или нет, что требуется доделать. On Tue, 5 Apr 2016, Ivan Zakharyaschev wrote: > On Fri, 1 Apr 2016, Ivan Zakharyaschev wrote: > >> (Им же в verify_elf делается LD_PRELOAD, чтобы не засорять лог сборки >> несущественными сообщениями об undefined symbols. Для случая, когда >> такая библиотека кладётся в системные /usr/lib/, есть макрос >> %requires_python_ABI_for_files; пример -- пакет boost или >> python3-module-pygobject или python-module-pygobject3. Иначе пакет не >> пропустят.) > > Появился механизм для проверки всяких .so-плагинов на undefined symbols. > Можно пользоваться (например, видел краем глаза обилие саодельных проверок в > спеке apache). В качестве примера с помощью него реализована: > > 1. проверка всего внутри python*/site-packages/ (раньше были warnings) > 2. а также макрос %requires_python3_ABI_for_files с явным указанием > интересных файлов. > > Принцип такой, что verify-elf понимает пары переменных окружения вида > RPM_LD_PRELOAD_xxxx и RPM_FILES_TO_LD_PRELOAD_xxxx (в случае одного из > питоноа в качестве идентификатора вместо xxxx выбрано python3, например). В нынешнем состоянии это нехорошо вот чем. Одна из прелестей успешного прохождения verify-elf (с unresolved=strict) в том, что наш автомат получается обучен тому, как загружать библиотеки и откуда взять все нужные символы. Это формальное знание можно использовать в lib.req, чтобы получить точные зависимости на множества требуемых символов. Принципиально этому ничего не мешает. Например, в случае расставления настоящих RPATH/RUNPATH достигается и прохождение verify-elf без замечаний, и получение кучи правильных зависимостей, которых бы иначе не увидел автомат. Но в случае с этим механизмом LD_PRELOAD для обработки "плагинов" первая часть реализована (verify-elf), а вторая-то в общем виде нет (lib.req). Конечно, макрос %requires_python3_ABI_for_files делает костыль-зависимость (вместо зависимости на конкретную libpython3.so или /usr/bin/python3, которые одинаковое ABI им предоставляют). Так что в этом случае вторая часть решена, но костыльно (и неточно, без завсимости на множества символов, что было бы ещё лучше). А в общем случае в нынешнем виде не очень хочется рекомендовать использовать этот механизм без реализации второй части, т.е. пользы от lib.req. Я тогда это не так хорошо осознавал, что они должны идти для пользы рука об руку: verify-elf и lib.req, поэтому предлагал вторую часть всем по-своему дописывать: > Поверх этого можно реализовывать нужные Вам макросы или задействовать > напрямую. > > Как предлагает glebfm@, чтобы ld-preload-ить программы, а не библиотеки, они > должны быть PIE. Думаю, можно было бы связать их теснее, и для RPM_LD_PRELOAD_xxxx генерировать просто всегда жёсткую зависимость вида: Requires: xxxx >= set:....... Тогда останется мейнтейнерам пакетов с xxxx ещё обеспечить появление соответствующих: Provides: xxxx = set:....... -- Best regards, Ivan --1807885841-1890473363-1482056027=:1300--