Feedback-ID: id4a34324:Fastmail
Date: Wed, 3 Apr 2024 15:16:03 -0700
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Magnus Hagander <magnus@hagander.net>, Bruce Momjian <bruce@momjian.us>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Security lessons from liblzma - libsystemd
Message-ID: <20240403221603.56nfpjfh6bqp45vw@awork3.anarazel.de>
References: <ZgdCpFThi9ODcCsJ@momjian.us>
 <20240403175721.l4r55sw4vcsrgpww@awork3.anarazel.de>
 <CABUevExoimjHPMMpAegci5mX13uOSPbZcWvycbwZwgey3c6P_w@mail.gmail.com>
 <385938.1712181535@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <385938.1712181535@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/20240403221603.56nfpjfh6bqp45vw%40awork3.anarazel.de>
Precedence: bulk

Hi,

On 2024-04-03 17:58:55 -0400, Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > On Wed, Apr 3, 2024 at 7:57 PM Andres Freund <andres@anarazel.de> wrote:
> >> Openssh has now integrated [1] a patch to remove the dependency on
> >> libsystemd
> >> for triggering service manager readyness notifications, by inlining the
> >> necessary function. That's not hard, the protocol is pretty simple.
> >> I suspect we should do the same. We're not even close to being a target as
> >> attractive as openssh, but still, it seems unnecessary.
> 
> > +1.
> 
> I didn't read the patch, but if it's short and stable enough then this
> seems like a good idea.

It's basically just checking for an env var, opening the unix socket indicated
by that, writing a string to it and closing the socket again.


> (If openssh and we are using such a patch, that will probably be a big
> enough stake in the ground to prevent somebody deciding to change the
> protocol ...)

One version of the openssh patch to remove liblzma was submitted by one of the
core systemd devs, so I think they agree that it's a stable API.  The current
protocol supports adding more information by adding attributes, so it should
be extensible enough anyway.


> >> An argument could be made to instead just remove support, but I think it's
> >> quite valuable to have intra service dependencies that can rely on the
> >> server actually having started up.
> 
> > If we remove support we're basically just asking most of our linux
> > packagers to add it back in, and they will add it back in the same way we
> > did it. I think we do everybody a disservice if we do that. It's useful
> > functionality.
> 
> Yeah, that idea seems particularly silly in view of the desire
> expressed earlier in this thread to reduce the number of patches
> carried by packagers.  People packaging for systemd-using distros
> will not consider that this functionality is optional.

Yep.

Greetings,

Andres Freund