On Sun, 2023-04-02 at 20:21 -0700, Noah Misch wrote:
> The most-plausible-to-me attack involves an ENABLE ALWAYS trigger
> that logs
> CURRENT_USER to an audit table.
How does requiring that the subscription owner have SET ROLE privileges
on the table owner help that case? As Robert pointed out, users coming
from v15 will have superuser subscription owners anyway, so the change
will be silent for them.
We need support to apply changes as the table owner, and we need that
to be the default; and this patch provides those things, and almost all
users of logical replication will be better off after this is
committed.
The small number of users for whom this new model is not good still
need the right documentation in front of them to understand the
consequences, so that they can opt out one way or another (as 0002
offers). Release notes are probably the most powerful tool we have for
notifying users, unfortunately. Requiring SET ROLE for users that are
almost certainly superusers doesn't give an opportunity to educate
people about the change in behavior.
As I said before, I'm fine with requiring that the subscription owner
can SET ROLE to the table owner for v16. It's the most conservative
choice and the most "correct" (in that no lesser privilege we have
today is a perfect match).
But I feel like we can do better in version 17 when we have time to
actually work through common use cases and the exceptional cases and
weight them appropriately. Like, how common is it to want to get the
user from a trigger on the subscriber side? Should that trigger be
using SESSION_USER instead of CURRENT_USER? Security is best when it
takes into account what people actually want to do and makes it easy to
do that securely.
Regards,
Jeff Davis