[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 17 Aug 2022 09:26:34 -0700
From: Elvis Pranskevichus <elvis@...edb.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] ldso/dynlink: Protect LD_ env vars from getting clobbered by apps
On Wednesday, August 17, 2022 8:29:05 AM PDT Rich Felker wrote:
> On Tue, Aug 16, 2022 at 10:45:45PM -0700, Elvis Pranskevichus wrote:
> > There is no guarantee that the environment block will remain intact.
> > For example, PostgreSQL clobbers argv/environ area to implement its
> > "setproctitle" emulation on non-BSD [1], and there is a popular
> > Python library inspired by it [2]. As a result, setting
> > `LD_LIBRARY_PATH` or `LD_PRELOAD` has no effect on Postgres
> > subprocesses when linking against musl.
>
> This is explicitly not allowed and is UB. This memory is not available
> for the application to clobber, and code attempting to do that needs
> to be patched out. Aside from the general principle, POSIX is very
> clear in the specification of environ:
>
> "Any application that directly modifies the pointers to which the
> environ variable points has undefined behavior."
I understand that what Postgres et al are doing is a nasty hack. My
thinking was that it is a question of compatibility with glibc's
behavior, which seems to tolerate these shenanigans (at least with
respect to `LD_*` variables. Good point regarding the allocator bringup
overhead, I haven't thought of that.
Thanks,
Elvis
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
