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