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