I wrote:
> =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
>> Thanks! Just one minor nitpick: setting an %ENV entry to `undef`
>> doesn't unset the environment variable, it sets it to the empty string.
>> To unset a variable it needs to be deleted from %ENV, i.e. `delete
>> $ENV{PGUSER};`.
> A
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Thanks! Just one minor nitpick: setting an %ENV entry to `undef`
> doesn't unset the environment variable, it sets it to the empty string.
> To unset a variable it needs to be deleted from %ENV, i.e. `delete
> $ENV{PGUSER};`.
Ah. Still, libpq
Tom Lane writes:
> =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
>> Tom Lane writes:
>>> I wonder if it'd be a good idea to convert
>>> auto_explain's TAP test to load auto_explain via session_preload_libraries
>>> instead of shared_preload_libraries, and then pass in the settings for
>>> e
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Tom Lane writes:
>> I wonder if it'd be a good idea to convert
>> auto_explain's TAP test to load auto_explain via session_preload_libraries
>> instead of shared_preload_libraries, and then pass in the settings for
>> each test via PGOPTIONS ins
Tom Lane writes:
> I wonder if it'd be a good idea to convert
> auto_explain's TAP test to load auto_explain via session_preload_libraries
> instead of shared_preload_libraries, and then pass in the settings for
> each test via PGOPTIONS instead of constantly rewriting postgresql.conf.
That whol
Nathan Bossart writes:
> Given all this, I think I'm inclined for the new argument.
Pushed like that then (after a bit more fooling with the comments).
I haven't done anything about a test case. We can't rely on plperl
getting built, and even if we could, it doesn't have any TAP-style
tests so
On Sun, Jul 24, 2022 at 11:49:23PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> I noticed that a couple of places check whether whereToSendOutput is set to
>> DestRemote to determine if this is an interactive session.
>
> IIRC, that would end in not loading the preload libraries in a standa
Nathan Bossart writes:
> I noticed that a couple of places check whether whereToSendOutput is set to
> DestRemote to determine if this is an interactive session.
IIRC, that would end in not loading the preload libraries in a standalone
backend. Perhaps that's what we want, but I'd supposed not.
On Sat, Jul 23, 2022 at 01:23:24PM -0400, Tom Lane wrote:
> - /*
> - * process any libraries that should be preloaded at backend start (this
> - * likewise can't be done until GUC settings are complete)
> - */
> - process_session_preload_libraries();
This patch essentially m
Nathan Bossart writes:
> On Fri, Jul 22, 2022 at 06:44:04PM -0400, Tom Lane wrote:
>> Another idea is to add a "bool interactive" parameter to InitPostgres,
>> thereby shoving the issue out to the call sites. Still wouldn't
>> expose the am_walsender angle, but conceivably it'd be more
>> future-
On Fri, Jul 22, 2022 at 06:44:04PM -0400, Tom Lane wrote:
> Another idea is to add a "bool interactive" parameter to InitPostgres,
> thereby shoving the issue out to the call sites. Still wouldn't
> expose the am_walsender angle, but conceivably it'd be more
> future-proof anyway?
I hesitated to
Nathan Bossart writes:
> On Fri, Jul 22, 2022 at 02:56:22PM -0400, Tom Lane wrote:
>> +if (!bootstrap &&
>> +!IsAutoVacuumWorkerProcess() &&
>> +!IsBackgroundWorker &&
>> +!am_walsender)
>> +process_session_preload_libraries();
> I worry that th
On Fri, Jul 22, 2022 at 02:56:22PM -0400, Tom Lane wrote:
> + /*
> + * If this is an interactive session, load any libraries that should be
> + * preloaded at backend start. Since those are determined by GUCs, this
> + * can't happen until GUC settings are complete, but we want
Kyotaro Horiguchi writes:
> At Fri, 22 Jul 2022 10:00:34 +0900, Michael Paquier
> wrote in
>> On Thu, Jul 21, 2022 at 05:39:35PM -0700, Gurjeet Singh wrote:
>>> The patch also adds an assertion in pg_parameter_aclcheck() to ensure
>>> that there's a transaction is in progress before it's called
At Fri, 22 Jul 2022 10:00:34 +0900, Michael Paquier wrote
in
> On Thu, Jul 21, 2022 at 05:39:35PM -0700, Gurjeet Singh wrote:
> > One notable side effect of this change is that
> > process_session_preload_libraries() is now called _before_ we
> > SetProcessingMode(NormalProcessing). Which means
On Thu, Jul 21, 2022 at 05:39:35PM -0700, Gurjeet Singh wrote:
> One notable side effect of this change is that
> process_session_preload_libraries() is now called _before_ we
> SetProcessingMode(NormalProcessing). Which means any database access
> performed by _PG_init() of an extension will be do
On Thu, Jul 21, 2022 at 4:35 PM Gurjeet Singh wrote:
> I like the idea of performing library initialization in
> InitPostgres(), as it performs the first transaction of the
> connection, and because of the libraries' ability to gin up new GUC
> variables that might need special handling, and also
On Thu, Jul 21, 2022 at 07:30:20PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> +StartTransactionCommand();
>> process_session_preload_libraries();
>> +CommitTransactionCommand();
>
> Yeah, that way would avoid any questions about changing the order of
> operations, but it seem
On Thu, Jul 21, 2022 at 3:29 PM Nathan Bossart wrote:
>
> On Thu, Jul 21, 2022 at 05:44:11PM -0400, Tom Lane wrote:
> > Right. So there are basically two things we could do about this:
> >
> > 1. set_config_option could decline to call pg_parameter_aclcheck
> > if not IsTransactionState(), instea
On Thu, Jul 21, 2022 at 2:44 PM Tom Lane wrote:
>
> Gurjeet Singh writes:
> > While poking at plperl's GUC in an internal discussion, I was able to
> > induce a crash (or an assertion failure in assert-enabled builds) as
> > an unprivileged user.
> > My investigation so far has revealed that the
Nathan Bossart writes:
> +StartTransactionCommand();
> process_session_preload_libraries();
> +CommitTransactionCommand();
Yeah, that way would avoid any questions about changing the order of
operations, but it seems like a mighty expensive solution: it's
adding a transaction to each
On Thu, Jul 21, 2022 at 05:44:11PM -0400, Tom Lane wrote:
> Right. So there are basically two things we could do about this:
>
> 1. set_config_option could decline to call pg_parameter_aclcheck
> if not IsTransactionState(), instead failing the assignment.
> This isn't a great answer because it w
Gurjeet Singh writes:
> While poking at plperl's GUC in an internal discussion, I was able to
> induce a crash (or an assertion failure in assert-enabled builds) as
> an unprivileged user.
> My investigation so far has revealed that the code path for the
> following condition has never been tested
On Wed, Jul 20, 2022 at 07:31:47PM -0700, Gurjeet Singh wrote:
> Moving the report from security to -hackers on Noah's advice. Since
> the function(s) involved in the crash are not present in any of the
> released versions, it is not considered a security issue.
>
> I can confirm that this is repr
egards,
Gurjeet
http://Gurje.et
Forwarded Conversation
Subject: Unprivileged user can induce crash by using an SUSET param in PGOPTIONS
From: Gurjeet Singh
Date: Mon, Jul 4, 2022 at 10:24 AM
To: Postgres Security
Cc: Bossart, Nathan
While poking at plperl's GUC
25 matches
Mail list logo
