Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rnSRR-00DNZV-6e for pgsql-bugs@arkaria.postgresql.org; Fri, 22 Mar 2024 00:07:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rnSRP-00HDDU-PN for pgsql-bugs@arkaria.postgresql.org; Fri, 22 Mar 2024 00:07:24 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rnSRP-00HDDK-EB for pgsql-bugs@lists.postgresql.org; Fri, 22 Mar 2024 00:07:24 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rnSRL-005kxk-NO for pgsql-bugs@lists.postgresql.org; Fri, 22 Mar 2024 00:07:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=momjian.us; s=2024011501; h=In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-ID:Content-Description; bh=dEj0VcZP+KPXwYAn8jvStOgYm0xhS+rVx4W5otLbhGQ=; b=cWpGtABJGGy05bKzzHQYwcVeqc CabfLMo81CEiCf42smvf7/lgO79uwY3YjTtM5FMPrfrBvXEic2E5gNjLOeI2Q54f5MArty734C99g LOeWFchs+AmN0MPFcUqGyljvwETgd7s+paxNeVW9pfH7vqLFyuaDXxyANO/BUiJBtsm/z74Dm6z7n JM0zHjwSizjAVyjwrvbz2ZNPrRzgWMDhi0SfRDvYaENtRyzGS9U75wn3nOnfsaROX0reAN4GdXOsI 7aTEm3GhX5rPs4rSmDx36EOIReHhle1oulkoJM2fCluC1DsG9MnkgXAv1RkklwOxAekLKArdXn4eU h5Q0wgtQ==; Received: from bruce by momjian.us with local (Exim 4.96) (envelope-from ) id 1rnSRG-004Fh1-22; Thu, 21 Mar 2024 20:07:14 -0400 Date: Thu, 21 Mar 2024 20:07:14 -0400 From: Bruce Momjian To: Thomas Munro Cc: walther@technowledgy.de, Peter Eisentraut , Christophe Pettus , Andrew Dunstan , PostgreSQL Bugs , Tom Lane Subject: Re: Regression tests fail with musl libc because libpq.so can't be loaded Message-ID: References: <4093813.1710899588@sss.pgh.pa.us> <4095435.1710900216@sss.pgh.pa.us> <477fa513-6bf0-456d-8d24-1e22a19df671@technowledgy.de> <36690fcf-f0c8-4d60-af49-6a7efa0e2b14@technowledgy.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="TLvhRbpbklWUu3IV" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --TLvhRbpbklWUu3IV Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Fri, Mar 22, 2024 at 11:42:52AM +1300, Thomas Munro wrote: > On Fri, Mar 22, 2024 at 9:30 AM wrote: > > > 4. The upstream (musl) suggestion of which I sent a PoC was to "exec > > > yourself with a bigger argv". > > > > We could do this in HEAD now ... > > Just a thought: if we want to go this way, do we need a new exec call? > We already control the initial exec in pg_ctl.c. > > > > Could we even use the exec-approach as the fallback in all other cases > > > except BSDs and Windows and get rid of PS_USE_NONE? > > > > ... and then remove PS_USE_NONE at the beginning of the v18 cycle. > > > > This would give a bit more time for those "other systems", which were > > previously falling back PS_USE_NONE and would then clobber argv, too. > > RIght. It's unspecified by POSIX whether ps shows changes to those > strings (and there are systems that don't), but it can't hurt to do so > anyway, and it'd be better than having a PS_USE_NONE code path that is > untested. I dimly recall that it turned out that PS_USE_NONE was > actually broken for a while without anyone noticing. Actually, I was thinking the opposite. Since the musl libc is widely used, it will be tested, and I don't want to disable process display updates for such a common platform. I suggest we use the #ifdef test to continue our existing behavior for the libraries we know about, like glibc, and use the LD_* process title truncation hack for libc's we don't recognize. Attached is a prototype patch which implements this based on previous patches. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you. --TLvhRbpbklWUu3IV Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="proctitle.diff" diff --git a/src/backend/utils/misc/ps_status.c b/src/backend/utils/misc/ps_status.c index 5d829e6e483..154862f9fb0 100644 --- a/src/backend/utils/misc/ps_status.c +++ b/src/backend/utils/misc/ps_status.c @@ -151,7 +151,32 @@ save_ps_display_args(int argc, char **argv) for (i = 0; environ[i] != NULL; i++) { if (end_of_area + 1 == environ[i]) - end_of_area = environ[i] + strlen(environ[i]); + { + + /* Do this for Linux libc libraries that might be unsafe. */ +#if ! defined(__linux__) || (! defined(__GLIBC__) && defined(__UCLIBC__ )) + /* + * If we see variables that the musl runtime linker is known + * to stash pointers to, give up so we don't break later calls + * to dlopen(). + */ + if (strstr(environ[i], "LD_LIBRARY_PATH=") == environ[i] || + strstr(environ[i], "LD_PRELOAD=") == environ[i]) + { + /* + * We can overwrite the name, but stop at the equals sign. + * Future loops will not find contiguous space, but we + * don't break early because we want to count the total + * number. + */ + end_of_area = strchr(environ[i], '='); + } + else +#endif + { + end_of_area = environ[i] + strlen(environ[i]); + } + } } ps_buffer = argv[0]; --TLvhRbpbklWUu3IV--