On Tue, 28 Mar 2023 at 18:13, Robert Haas <robertmh...@gmail.com> wrote: > > On Mon, Mar 27, 2023 at 6:08 PM Jelte Fennema <postg...@jeltef.nl> wrote: > > For high privileged subscription owners, > > we downgrade to the permissions of the table owner, but for low > > privileged ones we care about permissions of the subscription owner > > itself. > > Hmm. This is an interesting idea. A variant on this theme could be: > what if we made this an explicit configuration option?
Sounds perfect to me. Let's do that. As long as the old no-superuser tests continue to pass when disabling the new switch-to-table-owner behaviour, that sounds totally fine to me. I think it's probably easiest if you use the tests from my v2 patch when you add that option, since that was by far the thing I spent most time on to get right in the v2 patch. On Tue, 28 Mar 2023 at 18:13, Robert Haas <robertmh...@gmail.com> wrote: > > On Mon, Mar 27, 2023 at 6:08 PM Jelte Fennema <postg...@jeltef.nl> wrote: > > Attached is an updated version of your patch with what I had in mind > > (admittedly it needed one more line than "just" the return to make it > > work). But as you can see all previous tests for a lowly privileged > > subscription owner that **cannot** SET ROLE to the table owner > > continue to work as they did before. While still downgrading to the > > table owners role when the subscription owner **can** SET ROLE to the > > table owner. > > > > Obviously this needs some comments explaining what's going on and > > probably some code refactoring and/or variable renaming, but I hope > > it's clear what I meant now: For high privileged subscription owners, > > we downgrade to the permissions of the table owner, but for low > > privileged ones we care about permissions of the subscription owner > > itself. > > Hmm. This is an interesting idea. A variant on this theme could be: > what if we made this an explicit configuration option? > > I'm worried that if we just try to switch users and silently fall back > to not doing so when we don't have enough permissions, the resulting > behavior is going to be difficult to understand and troubleshoot. I'm > thinking that maybe if you let people pick the behavior they want that > becomes more comprehensible. It's also a nice insurance policy: say > for the sake of argument we make switch-to-table-owner the new > default. If that new behavior causes something to happen to somebody > that they don't like, they can always turn it off, even if they are a > highly privileged user who doesn't "need" to turn it off. > > -- > Robert Haas > EDB: http://www.enterprisedb.com
