> 31 дек. 2020 г., в 00:37, Paul Martinez написал(а):
>
> In Google Cloud SQL we create a role for customers, cloudsqlsuperuser,
> which, confusingly, is not a SUPERUSER, but does have some extra
> permissions. We've modified a lot of "if (!superuser())" checks to
> "if (!superuser() && !cloud
Greetings,
* Paul Martinez (paul...@google.com) wrote:
> You've identified exactly the problem we're running into -- we want to
> allow customers, who aren't superusers, to create replication roles.
This is also where it's probably useful to think about what the impact
of that is- after all, sinc
On Wed, Dec 30, 2020 at 12:28 PM Andrey Borodin wrote:
> I think that sharing "various small changes to permission checks" is a really
> good idea.
>
> > 30 дек. 2020 г., в 20:39, Stephen Frost написал(а):
> > In other words, I suspect people would be happier if we
> > provided a way for non-sup
> 30 дек. 2020 г., в 20:26, Stephen Frost написал(а):
>
> I'd strongly suggest that, instead, you consider proposing changes which
> would address the actual use cases you have and work with the community
> to have those included in core, which would further have the added
> property that ever
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Tue, Dec 29, 2020 at 02:26:19PM -0600, Paul Martinez wrote:
> > The checks for whether the current user can create a user with the
> > SUPERUSER,
> > REPLICATION, or BYPASSRLS attributes are chained together using if/else-if,
> > befo
Greetings,
* Paul Martinez (paul...@google.com) wrote:
> This small patch simply modifies the code to replace the if/else-if chain with
> separate if statements, and always checks whether the user has the CREATEROLE
> privilege. (The have_createrole_privilege function includes another superuser
>
On Tue, Dec 29, 2020 at 02:26:19PM -0600, Paul Martinez wrote:
> The checks for whether the current user can create a user with the SUPERUSER,
> REPLICATION, or BYPASSRLS attributes are chained together using if/else-if,
> before finally checking whether the user has CREATEROLE privileges in a
> fi
Hey, hackers,
As part of building Postgres for a managed environment in Google Cloud SQL,
we've made various small changes to permission checks to carefully limit what
customers have access to.
We were making some changes in src/backend/commands/user.c and noticed some
clunky logic related to ver
