Re: Questions about the new subscription parameter: password_required

From: Benoit Lobréau <benoit(dot)lobreau(at)dalibo(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>
Subject: Re: Questions about the new subscription parameter: password_required
Date: 2023-09-26 14:27:03
Message-ID: c737712c-b960-59a4-62d2-2815b2e1b362@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/22/23 21:58, Robert Haas wrote
> I think that there normally shouldn't be any problem here, because if
> form->subpasswordrequired is true, we expect that the connection
> string should contain a password which the remote side actually uses,
> or we expect the subscription to be owned by the superuser. If neither
> of those things is the case, then either the superuser made a
> subscription that doesn't use a password owned by a non-superuser
> without fixing subpasswordrequired, or else the configuration on the
> remote side has changed so that it now doesn't use the password when
> formerly it did. In the first case, perhaps it would be fine to go
> ahead and drop the slot, but in the second case I don't think it's OK
> from a security point view, because the command is going to behave the
> same way no matter who executes the drop command, and a non-superuser
> who drops the slot shouldn't be permitted to rely on the postgres
> processes's identity to do anything on a remote node -- including
> dropping a relation slot. So I tentatively think that this behavior is
> correct.

I must admin I hadn't considered the implication when the configuration
on the remote side has changed and we use a non-superuser. I see how it
could be problematic.

I will try to come up with a documentation patch.

> Maybe you're altering it in a way that doesn't involve any connections
> or any changes to the connection string? There's no security issue if,
> say, you rename it.

I looked at the code again. Indeed, of the ALTER SUBSCRIPTION commands,
only ALTER SUBSCRIPTION .. CONNECTION uses walrcv_check_conninfo().

I checked the other thread (Re: [16+] subscription can end up in
inconsistent state [1]) and will try the patch. Is it the thread you
where refering to earlier ?

[1]
https://www.postgresql.org/message-id/flat/5dff4caf26f45ce224a33a5e18e110b93a351b2f.camel%40j-davis.com#ff4a06505de317b1ad436b8102a69446

--
Benoit Lobréau
Consultant
http://dalibo.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message jacktby jacktby 2023-09-26 14:31:09 Index AmInsert Parameter Confused?
Previous Message Bruce Momjian 2023-09-26 14:16:30 Re: Partial aggregates pushdown