Re: Questions about the new subscription parameter: password_required
От | Benoit Lobréau |
---|---|
Тема | Re: Questions about the new subscription parameter: password_required |
Дата | |
Msg-id | c737712c-b960-59a4-62d2-2815b2e1b362@dalibo.com обсуждение исходный текст |
Ответ на | Re: Questions about the new subscription parameter: password_required (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Questions about the new subscription parameter: password_required
|
Список | 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
В списке pgsql-hackers по дате отправления: