Re: Regression tests fail with musl libc because libpq.so can't be loaded

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Regression tests fail with musl libc because libpq.so can't be loaded
Дата
Msg-id CA+hUKGJzC4rr2Yr=QZyx9W83Wv=TVJHndKF1anjNLNXVUM7TqQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Regression tests fail with musl libc because libpq.so can't be loaded  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Regression tests fail with musl libc because libpq.so can't be loaded  (Wolfgang Walther <walther@technowledgy.de>)
Re: Regression tests fail with musl libc because libpq.so can't be loaded  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-bugs
On Thu, Mar 21, 2024 at 2:35 AM Bruce Momjian <bruce@momjian.us> wrote:
> Yes, I prefer this.  I am worried the environ hackery will bite us
> someday and the cause will be hard to find.

Some speculation on how widespread this trick is: as mentioned, it
seems to come from sendmail (I didn't spend the time to find a repo
that has ancient versions, so this is someone's random snapshot repo,
but it's referring to pretty old dead systems):

https://github.com/Distrotech/sendmail/blob/master/sendmail/conf.c#L2436

That was once ubiquitous, back in the day.  One of the most widespread
envon-clobberers these days must be openssh:


https://github.com/openssh/openssh-portable/blob/86bdd3853f4d32c85e295e6216a2fe0953ad93f0/openbsd-compat/setproctitle.c#L69

And funnily enough, googling LD_LIBRARY_PATH and openssh brings up a
few unsolved/unanswered questions about mysterious breakage (though I
didn't see any that mentioned musl by name and there could be other
explanations, *shrug*).

There is also Chromium/Chrome:

https://github.com/chromium/chromium/blob/main/base/process/set_process_title_linux.cc#L136

That code has some interesting commentary and points to a commit in
Linux which mentions setproctitle() and making sure it still works
(funny because setproctitle() isn't a function in any standard
userspace library AFAIK so I guess it just means the trick in
general), and also mentions the failure of attempts to get an official
way to do this negotiated between the relevant projects.

Of course we have to distinguish between the basic argv[] clobbering
trick which is barely even a trick, and the more advanced environ
stealing trick which confuses musl.  A very widespread user of the
basic trick would be systemd, which tries to use the prctl() if it can
to get a much bigger window of memory to write on, but otherwise falls
back to accepting a small one.  I guess we'd do the same if we could,
ie if a future Linux version didn't require CAP_SYS_RESOURCES to do
it:

https://github.com/systemd/systemd/blob/8810b782a17050d7f7a870b975f09e8a690b7bea/src/basic/argv-util.c

Anyway, it looks like there is plenty of will out there to keep this
working, albeit in a weird semi-supported state whose cruftiness is
undeniable.



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #18403: PL/pgSQL is reporting unexpected errors when processing DECLARE blocks with <
Следующее
От: "Andrey M. Borodin"
Дата:
Сообщение: Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum