Re: [PATCH] Log details for client certificate failures - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: [PATCH] Log details for client certificate failures
Date
Msg-id CAAWbhmgsvHrH9wLU2kYc3pOi1KSenHSLAHBbCVmmddW6-mc_=w@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Log details for client certificate failures  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] Log details for client certificate failures
List pgsql-hackers
On Wed, Jul 20, 2022 at 3:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jacob Champion <jchampion@timescale.com> writes:
> > I'm currently hardcoding an elevel of ERROR on the new guc_strdup()s,
> > because that seems to be a common case for the check hooks.
>
> Really?  That's almost certainly NOT okay.  As an example, if you
> have a problem with a new value loaded from postgresql.conf during
> SIGHUP processing, throwing ERROR will cause the postmaster to exit.

v4 attempts to fix this by letting the check hooks pass
MCXT_ALLOC_NO_OOM to pg_clean_ascii(). (It's ignored in the frontend,
which just mallocs.)

> I wouldn't be too surprised if there are isolated cases where people
> didn't understand what they were doing and wrote that, but that
> needs to be fixed not emulated.

I might be missing something, but in guc.c at least it appears to be
the rule and not the exception.

Thanks,
--Jacob

Attachment

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Fwd: Unprivileged user can induce crash by using an SUSET param in PGOPTIONS
Next
From: Tom Lane
Date:
Subject: Re: Fwd: Unprivileged user can induce crash by using an SUSET param in PGOPTIONS