> On Nov 1, 2021, at 2:05 PM, Stephen Frost wrote:
>
> I'm not quite following how your response here is addressing the
> point that I brought up in what was quoted above it.
Could you clarify which question I didn't answer? I fear I may have left
something unanswered, but I don't know to
> On Nov 1, 2021, at 2:00 PM, Stephen Frost wrote:
> I've not directly looked at that patch, but I like it based on the name,
> if we think we can actually get folks to agree to is as it's quite a
> change from the current situation. Previously I've felt that we
> wouldn't have support for
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Nov 1, 2021, at 1:13 PM, Stephen Frost wrote:
> >> Having Batman *own* all residents in Gotham city would work, if we can
> >> agree on a role ownership system. It has the downside that only a role's
> >> (direct or
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Nov 1, 2021, at 12:44 PM, Stephen Frost wrote:
> > I can generally get behind the idea that a user who has been allowed to
> > create other roles should be able to do various other things with that
> > role, but should also be
> On Nov 1, 2021, at 1:13 PM, Stephen Frost wrote:
>
>> Having Batman *own* all residents in Gotham city would work, if we can agree
>> on a role ownership system. It has the downside that only a role's (direct
>> or indirect) owner can do the auditing, though. That's more flexible than
> On Nov 1, 2021, at 12:44 PM, Stephen Frost wrote:
>
> I can generally get behind the idea that a user who has been allowed to
> create other roles should be able to do various other things with that
> role, but should also be limited by what rights they themselves have
> (unlike how
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Oct 25, 2021, at 11:30 AM, Stephen Frost wrote:
>
> > Consider instead:
> >
> > CREATE ROLE X;
> > CREATE ROLE Y;
> > CREATE ROLE Z;
> >
> > GRANT Y to X;
> > GRANT Z to X;
> >
> > SET ROLE X;
> > CREATE EVENT TRIGGER FOR
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Oct 29, 2021, at 4:46 PM, Jeff Davis wrote:
> > But I don't think the concept of role ownership has zero potential
> > confusion, either. For instance, I could certainly imagine a user A
> > creating a role B (and therefore
> On Oct 29, 2021, at 4:46 PM, Jeff Davis wrote:
>
> But I don't think the concept of role ownership has zero potential
> confusion, either. For instance, I could certainly imagine a user A
> creating a role B (and therefore owning it), and then doing "GRANT A TO
> B". Is there a reason to do
On Fri, Oct 29, 2021 at 6:56 PM Jeff Davis wrote:
> On Wed, 2021-10-27 at 16:10 -0400, Robert Haas wrote:
> > But the thing that defines a tenant need not be a role. It can be
> > some
> > other kind of object. Suppose we invent a CREATE TENANT command.
>
> Would it be a recursive concept? Could
On Thu, 2021-10-28 at 11:02 -0700, Mark Dilger wrote:
> It feels to me that the traditional concept of users and groups could
> map, one-to-one, onto users and roles, but we've mapped both users
> and groups, many-to-one, onto roles, leaving no distinct concept of
> groups, and now we're proposing
On Wed, 2021-10-27 at 16:10 -0400, Robert Haas wrote:
> But the thing that defines a tenant need not be a role. It can be
> some
> other kind of object. Suppose we invent a CREATE TENANT command.
Would it be a recursive concept? Could a tenant create a sub-tenant?
Regards,
Jeff Davis
> On Oct 27, 2021, at 1:10 PM, Robert Haas wrote:
>
> This is effectively the same thing as Mark's proposal, but just using
> a new kind of object (TENANT) where Mark used an existing kind of
> object (ROLE). And it addresses Noah's concern, perhaps, because with
> the approach the tenant
On Mon, Oct 25, 2021 at 3:25 PM Robert Haas wrote:
> But also, Noah writes: "Also, it's currently a best practice for only
> non-LOGIN roles to have members. The proposed approach invites folks
> to abandon that best practice."
>
> The kind of mechanism you're proposing here doesn't seem to make
> On Oct 25, 2021, at 11:30 AM, Stephen Frost wrote:
> Consider instead:
>
> CREATE ROLE X;
> CREATE ROLE Y;
> CREATE ROLE Z;
>
> GRANT Y to X;
> GRANT Z to X;
>
> SET ROLE X;
> CREATE EVENT TRIGGER FOR Y do_stuff();
>
> Now, X has explicitly said that they want the event trigger to fire
On Mon, Oct 25, 2021 at 2:30 PM Stephen Frost wrote:
> Does membership in role Y cause the event trigger to fire for that role?
> I'd argue that the answer is probably 'yes', but at least it's no longer
> tied back to membership in X (the owner of the trigger). That Noah
> explicitly mentioned
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Oct 25, 2021 at 12:20 PM Stephen Frost wrote:
> > > Exactly. That's the main point. Also, it's currently a best practice for
> > > only non-LOGIN roles to have members. The proposed approach invites
> > > folks to
> > >
On Mon, Oct 25, 2021 at 12:20 PM Stephen Frost wrote:
> > Exactly. That's the main point. Also, it's currently a best practice for
> > only non-LOGIN roles to have members. The proposed approach invites folks
> > to
> > abandon that best practice. I take the two smells as a sign that we'll
Greetings,
* Noah Misch (n...@leadboat.com) wrote:
> On Wed, Oct 20, 2021 at 11:27:11AM -0700, Jeff Davis wrote:
> > On Wed, 2021-10-20 at 10:32 -0700, Mark Dilger wrote:
> > > I'd like to have a much clearer understanding of Noah's complaint
> > > first. There are multiple things to consider:
On Wed, Oct 20, 2021 at 11:27:11AM -0700, Jeff Davis wrote:
> On Wed, 2021-10-20 at 10:32 -0700, Mark Dilger wrote:
> > I'd like to have a much clearer understanding of Noah's complaint
> > first. There are multiple things to consider: (1) the role which
> > owns the trigger, (2) the role which
On Wed, 2021-10-20 at 16:36 -0400, Stephen Frost wrote:
> > I think that's basically giving up the important part of this idea,
> > which is to allow meaningful administration without superuser
> > privileges. "highly-privileged roles only" sounds like in practice
> > it
> > would amount to the
Greetings,
On Wed, Oct 20, 2021 at 16:23 Robert Haas wrote:
> On Wed, Oct 20, 2021 at 1:20 PM Jeff Davis wrote:
> > A downside is that with my suggestion, event triggers would still be
> > for the highly-privileged roles only. Allowing unprivileged users to
> > create event triggers that have
On Wed, Oct 20, 2021 at 1:20 PM Jeff Davis wrote:
> A downside is that with my suggestion, event triggers would still be
> for the highly-privileged roles only. Allowing unprivileged users to
> create event triggers that have limited scope might allow some really
> interesting use cases. There
On Thu, 2021-05-27 at 23:06 -0700, Noah Misch wrote:
> pg_logical_replication would not be safe to delegate that way:
>
https://postgr.es/m/flat/CACqFVBbx6PDq%2B%3DvHM0n78kHzn8tvOM-kGO_2q_q0zNAMT%2BTzdA%40mail.gmail.com
What do you mean "that way"? Do you mean it's not safe to delegate
I have now received multiple requests to split this patchset into multiple
parts, including some off-list. I'll be posting four new patch sets on four
new topics:
New privileged roles which can SET and ALTER SYSTEM SET (v8-0002 through
v8-0013)
Non-superuser event trigger owners (v8-0014
On Wed, 2021-10-20 at 10:32 -0700, Mark Dilger wrote:
> I'd like to have a much clearer understanding of Noah's complaint
> first. There are multiple things to consider: (1) the role which
> owns the trigger, (2) the role which is performing an action which
> would cause the trigger to fire, (3)
> On Oct 20, 2021, at 10:20 AM, Jeff Davis wrote:
>
> I'm trying to suggest an approach that is flexible enough (not limited
> to superusers), but also addresses Noah's complaint that ordinary role
> membership should not implicitly control event trigger firing.
>
> The most direct way to
On Tue, 2021-10-19 at 18:52 -0400, Stephen Frost wrote:
> > The implementation in the patch set does this, but with finer
> > grained precision, because the universe of roles is divided into
> > more than just superuser vs. non-superuser.
>
> This last point is particularly important. Non-super
Greetings,
On Tue, Oct 19, 2021 at 18:26 Mark Dilger
wrote:
>
>
> > On Oct 19, 2021, at 3:18 PM, Jeff Davis wrote:
> >
> > On Tue, 2021-10-19 at 13:17 -0700, Mark Dilger wrote:
> >> Wouldn't it be much cleaner to have superuser bypass the trigger?
> >
> > Maybe it could be a user property like
> On Oct 19, 2021, at 3:18 PM, Jeff Davis wrote:
>
> On Tue, 2021-10-19 at 13:17 -0700, Mark Dilger wrote:
>> Wouldn't it be much cleaner to have superuser bypass the trigger?
>
> Maybe it could be a user property like "BYPASS_EVENT_TRIGGERS", and
> only superusers could adjust it (like the
On Tue, 2021-10-19 at 13:17 -0700, Mark Dilger wrote:
> Wouldn't it be much cleaner to have superuser bypass the trigger?
Maybe it could be a user property like "BYPASS_EVENT_TRIGGERS", and
only superusers could adjust it (like the SUPERUSER and REPLICATION
properties).
I suppose it would
> On Oct 19, 2021, at 12:28 PM, Jeff Davis wrote:
>
> On Mon, 2021-09-27 at 11:15 -0700, Mark Dilger wrote:
>> Allow non-superusers to create event triggers. The logic already
>> existed and is unchanged to handle event triggers owned by non-
>> superusers and conditioning those triggers
On Mon, 2021-09-27 at 11:15 -0700, Mark Dilger wrote:
> Allow non-superusers to create event triggers. The logic already
> existed and is unchanged to handle event triggers owned by non-
> superusers and conditioning those triggers firing on the (trigger-
> owner, role-performing-event) pair.
Le lundi 27 septembre 2021, 20:15:05 CEST Mark Dilger a écrit :
> > On Sep 21, 2021, at 12:58 PM, Andrew Dunstan wrote:
> >
> > This patch set is failing to apply for me - it fails on patch 2.
>
> Thanks for looking! I have pulled together a new patch set which applies
> cleanly against
On Thu, Oct 7, 2021 at 10:29 PM Mark Dilger
wrote:
> > I have a question: it looks like the view pg_backend_memory_contexts
> > and the function pg_log_backend_memory_contexts are superuser only.
> > Isn't it a good idea to allow users with a pg_monitor or some other
> > similar role to use these
> On Oct 6, 2021, at 10:48 PM, Bharath Rupireddy
> wrote:
>
> Hi Mark, thanks for this work. I'm late to be here in this thread,
> please note that I didn't go through the entire thread as it is quite
> long for me to read.
Thanks for joining.
> I have a question: it looks like the view
On Mon, Oct 4, 2021 at 8:22 PM Bossart, Nathan wrote:
> The changes for adding GUC management roles seem pretty
> straightforward and would likely be helpful for service providers.
> However, I was kind of surprised that membership to such roles also
> provided access to ALTER SYSTEM SET. IMO
On Mon, Sep 27, 2021 at 11:45 PM Mark Dilger
wrote:
>
> Thanks for looking! I have pulled together a new patch set which applies
> cleanly against current master.
Hi Mark, thanks for this work. I'm late to be here in this thread,
please note that I didn't go through the entire thread as it is
On 10/4/21, 7:08 PM, "Stephen Frost" wrote:
> I really think we need to stop addressing roles explicitly as
> 'superuser' vs. 'non-superuser', because a non-superuser role can be
> GRANT'd a superuser role, which makes that distinction really not
> sensible. This has continued to be a problem
Greetings,
* Bossart, Nathan (bossa...@amazon.com) wrote:
> On 9/27/21, 11:16 AM, "Mark Dilger" wrote:
> > On Sep 21, 2021, at 12:58 PM, Andrew Dunstan wrote:
> >> I do like the basic thrust of reducing the power of CREATEROLE. There's
> >> an old legal maxim I learned in my distant youth that
On 9/27/21, 11:16 AM, "Mark Dilger" wrote:
> On Sep 21, 2021, at 12:58 PM, Andrew Dunstan wrote:
>> I do like the basic thrust of reducing the power of CREATEROLE. There's
>> an old legal maxim I learned in my distant youth that says "nemo dat
>> quod non habet" - Nobody can give something they
> On Sep 21, 2021, at 12:58 PM, Andrew Dunstan wrote:
>
> This patch set is failing to apply for me - it fails on patch 2.
Thanks for looking! I have pulled together a new patch set which applies
cleanly against current master.
> I haven't dug terribly deeply into it yet, but I notice that
On 9/15/21 10:38 AM, Mark Dilger wrote:
>> On Aug 31, 2021, at 6:41 PM, Mark Dilger
>> wrote:
>>
>>
> Synopsis:
>
> The major change in version 7 is a reworking of role ownership and the
> CREATEROLE attribute to make it no longer a near-superuser privilege. This
> new functionality is in
> On Aug 23, 2021, at 1:46 PM, Stephen Frost wrote:
>
> I'd much rather we go down the path that Robert had suggested where we
> find a way to make a connection between the tenant role and everything
> that they create, and leave everything that is outside of that box on
> the other side of
> On Aug 23, 2021, at 11:13 AM, Stephen Frost wrote:
>
>> Patch v5-0011 is a bug fix posted elsewhere that hasn't been committed yet
>> but which must be committed in preparation for v5-0012.
>
> No idea what it is as I hadn't looked yet, but if it's a bug fix then
> shouldn't it be
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Aug 23, 2021, at 12:51 PM, Stephen Frost wrote:
> > Simply using superuser_arg() isn't sufficient is exactly the point that
> > I'm trying to make. As a 'landlord', I might very well want to have
> > some kind of 'landlord'
> On Aug 23, 2021, at 12:51 PM, Stephen Frost wrote:
>
> Simply using superuser_arg() isn't sufficient is exactly the point that
> I'm trying to make. As a 'landlord', I might very well want to have
> some kind of 'landlord' role that isn't directly a superuser but which
> could *become* a
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Aug 23, 2021, at 11:13 AM, Stephen Frost wrote:
> > This I have to object to pretty strongly- we have got to get away from
> > the idea that just because X isn't a superuser or isn't owned by a
> > superuser that it's fine to
> On Aug 23, 2021, at 11:13 AM, Stephen Frost wrote:
>
> This I have to object to pretty strongly- we have got to get away from
> the idea that just because X isn't a superuser or isn't owned by a
> superuser that it's fine to allow some non-superuser to mess with it.
I thought we were
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Aug 23, 2021 at 2:13 PM Stephen Frost
> wrote:> This I have to object to pretty strongly- we have got to get
> away from
> > the idea that just because X isn't a superuser or isn't owned by a
> > superuser that it's fine to allow
On Mon, Aug 23, 2021 at 2:13 PM Stephen Frost
wrote:> This I have to object to pretty strongly- we have got to get
away from
> the idea that just because X isn't a superuser or isn't owned by a
> superuser that it's fine to allow some non-superuser to mess with it.
> In particlar, just because a
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Jul 22, 2021, at 1:01 PM, Robert Haas wrote:
> > It's awkward. I think that we can't afford to create a separate
> > predefined role for every single thing that someone could
> > theoretically want to sever, because then we'll
Robert Haas writes:
> Dang it, yes. The tenant needs to be members of all the other users,
> not the other way around. I spent a long time trying to not get that
> backwards and still did.
The "membership" terminology is inherently confusing I fear.
Maybe better to say that all the
On Tue, Jul 27, 2021 at 10:24 AM Isaac Morland wrote:
> Isn’t this backwards? If all those roles are members of "tenant" then they
> can do anything "tenant" can do. The reverse might work - make "tenant" a
> member of all the related roles - although I haven’t thought through in
> detail.
On Tue, 27 Jul 2021 at 10:19, Robert Haas wrote:
> I think this has potential. In a managed services environment, you can
> imagine the provider as the super-duper user, having the ability to do
> anything - because they control the box, so there's really no stopping
> it - but presumably very
On Mon, Jul 26, 2021 at 4:58 PM Tom Lane wrote:
> After further thought, I can't poke a hole in that concept.
> We'd keep the rule that the trigger executes as the calling user.
> Therefore, the trigger cannot perform any action that the calling
> user couldn't do if she chose. Conversely, since
On Mon, Jul 26, 2021 at 4:28 PM Stephen Frost wrote:
> so ... yes and no. There's an awful lot being ascribed to
> 'administrator' without any definition of it being actually given. We
> are working in this thread to explicitly split up superuser privileges
> to allow them to be granted to
Alvaro Herrera writes:
> On 2021-Jul-26, Tom Lane wrote:
>> Uh, why not? If you own the trigger, you can drop it, so why shouldn't
>> you be able to temporarily disable it?
> I think an auditing system that can be turned off by the audited user is
> pretty much useless. Or did I misunderstood
On 2021-Jul-26, Tom Lane wrote:
> Stephen Frost writes:
> > ... Tom's suggestion
> > would work, of course, but it would mean having to create event triggers
> > for all the roles in the system, and would those roles who own those
> > event triggers be able to disable them..?
>
> Uh, why not?
Stephen Frost writes:
> ... Tom's suggestion
> would work, of course, but it would mean having to create event triggers
> for all the roles in the system, and would those roles who own those
> event triggers be able to disable them..?
Uh, why not? If you own the trigger, you can drop it, so why
I wrote:
> Possibly this could be generalized to "fire on commands performed by
> any role the trigger owner is a member of", but then I'm a bit less
> sure that it's safe from both roles' perspectives.
After further thought, I can't poke a hole in that concept.
We'd keep the rule that the
Greetings,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> On 2021-Jul-26, Tom Lane wrote:
>
> > What if we allow event triggers owned by non-superusers, but only fire
> > them on commands performed by the trigger's owner? This sidesteps all
> > the issues of who has which privileges and
On 2021-Jul-26, Tom Lane wrote:
> What if we allow event triggers owned by non-superusers, but only fire
> them on commands performed by the trigger's owner? This sidesteps all
> the issues of who has which privileges and whether Alice is malicious
> towards Bob or vice versa, because there is
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jul 26, 2021 at 4:12 PM Robert Haas wrote:
> > I think I may not have expressed myself clearly enough here. What I'm
> > concerned about is: Alice should not be permitted to preventing Bob
> > from doing something which Bob is
> On Jul 26, 2021, at 1:12 PM, Robert Haas wrote:
>
> Alice should not be permitted to preventing Bob
> from doing something which Bob is allowed to do and Alice is not
> allowed to do.
That sounds intuitively reasonable, though it depends on what "which Bob is
allowed to do" means. For
Stephen Frost writes:
> As I understood Mark's suggestion, the trigger would run but would have
> the privileges of the intersection of both user's permissions, which is
> an interesting idea but not one we've got any way to really do today as
> each privilege check would now need to check two
On Mon, Jul 26, 2021 at 4:12 PM Robert Haas wrote:
> I think I may not have expressed myself clearly enough here. What I'm
> concerned about is: Alice should not be permitted to preventing Bob
> from doing something which Bob is allowed to do and Alice is not
> allowed to do. If Alice is the
On Mon, Jul 26, 2021 at 4:05 PM Stephen Frost wrote:
> As I understood Mark's suggestion, the trigger would run but would have
> the privileges of the intersection of both user's permissions, which is
> an interesting idea but not one we've got any way to really do today as
> each privilege check
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jul 23, 2021 at 4:57 PM Mark Dilger
> wrote:
> > > On Jul 23, 2021, at 1:54 PM, Robert Haas wrote:
> > > Yeah, but you're inventing a system for allowing the restriction on a
> > > GUC to be something other than is-superuser in
On Fri, Jul 23, 2021 at 4:57 PM Mark Dilger
wrote:
> > On Jul 23, 2021, at 1:54 PM, Robert Haas wrote:
> > Yeah, but you're inventing a system for allowing the restriction on a
> > GUC to be something other than is-superuser in the very patch we're
> > talking about. So it could be something
> On Jul 23, 2021, at 2:04 PM, Mark Dilger wrote:
>
> If the GUC merely converts the event trigger into an error, then you have the
> problem that the customer can create event triggers which the service
> provider will need to disable (because they cause the service providers
> legitimate
> On Jul 23, 2021, at 1:57 PM, Mark Dilger wrote:
>
> What's the point in having these as separate roles if they can circumvent
> each other's authority?
That was probably too brief a reply, so let me try again. If the GUC
circumvents the event trigger, then my answer above stands. If
> On Jul 23, 2021, at 1:54 PM, Robert Haas wrote:
>
> Yeah, but you're inventing a system for allowing the restriction on a
> GUC to be something other than is-superuser in the very patch we're
> talking about. So it could be something like is-database-security.
> Therefore I don't grok the
On Fri, Jul 23, 2021 at 12:11 PM Mark Dilger
wrote:
> A superuser-only GUC for this is also a bit too heavy handed.
Yeah, but you're inventing a system for allowing the restriction on a
GUC to be something other than is-superuser in the very patch we're
talking about. So it could be something
> On Jul 23, 2021, at 9:20 AM, Stephen Frost wrote:
>
> These considerations were addressed with row_security by allowing the
> GUC to be set by anyone, but throwing an ERROR if RLS would have been
> required by the query instead of just allowing it. I don't see any
> obvious reason why that
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Jul 23, 2021, at 6:22 AM, Robert Haas wrote:
> > And I think that's a good illustration of why it's a bad idea to
> > categorize things according to whether or not they have a certain
> > consequence.
>
> Well, one very big
> On Jul 23, 2021, at 6:22 AM, Robert Haas wrote:
>
> And I think that's a good illustration of why it's a bad idea to
> categorize things according to whether or not they have a certain
> consequence.
Well, one very big reason for wanting to break superuser into separate roles is
to make
On Thu, Jul 22, 2021 at 5:35 PM Mark Dilger
wrote:
> I agree with the need to document the theory behind all this. Event triggers
> are dangerous because they can trap a superuser into executing code they do
> not intend:
That's true. Regular triggers and views can also do that, and so can
> On Jul 22, 2021, at 11:21 AM, Robert Haas wrote:
>
> When we come to the
> third thing the patch includes in this category, creating and dropping
> event triggers, I *really* don't understand why that one is considered
> host security. That one isn't touching the filesystem even to the
>
On Thu, Jul 22, 2021 at 3:00 PM Stephen Frost wrote:
> I'm a bit on the fence about the documentation side... I could be
> convinced either way, really, but I generally agree that it'd be good to
> pick one and be consistent. I don't think the places where we do/don't
> mention it were done for
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jul 1, 2021 at 11:59 AM Mark Dilger
> wrote
> > > On Jun 29, 2021, at 6:25 PM, Mark Dilger
> > > wrote:
> > > Please find attached a new set of patches.
> >
> > And again, this time attaching a fifth patch which includes the
On Thu, Jul 22, 2021 at 1:29 PM Mark Dilger
wrote:
> Certainly not. What I meant on May 28 by "eventually" was that the patch set
> (posted May 25 and named "v3") had not yet implemented such security, as I
> was fishing for comments from the community about whether the basic division
> of
On Thu, Jul 1, 2021 at 11:59 AM Mark Dilger wrote
> > On Jun 29, 2021, at 6:25 PM, Mark Dilger
> > wrote:
> > Please find attached a new set of patches.
>
> And again, this time attaching a fifth patch which includes the work to allow
> users who belong to the right security role to SET and
> On Jul 22, 2021, at 8:29 AM, Robert Haas wrote:
>
> I don't think that we want to commit a patch to add a
> pg_logical_replication role that can "eventually" be made staff to
> delegate to non-superusers.
Certainly not. What I meant on May 28 by "eventually" was that the patch set
On Fri, May 28, 2021 at 1:42 PM Mark Dilger
wrote:
> > pg_logical_replication would not be safe to delegate that way:
> > https://postgr.es/m/flat/CACqFVBbx6PDq%2B%3DvHM0n78kHzn8tvOM-kGO_2q_q0zNAMT%2BTzdA%40mail.gmail.com
>
> Oh, I agree that this patch set does not go the extra step to make it
On Thu, Jul 1, 2021 at 9:42 PM Mark Dilger wrote:
>
>
>
> > On Jun 29, 2021, at 6:25 PM, Mark Dilger
> > wrote:
> >
> > Please find attached a new set of patches.
>
> And again, this time attaching a fifth patch which includes the work to allow
> users who belong to the right security role to
> On Jul 5, 2021, at 1:50 AM, Andrey Borodin wrote:
>
> I'm not sure, but maybe we should allow replication role to change
> session_replication_role?
Thanks, Andrey, for taking a look.
Yes, there is certainly some logic to that suggestion. The patch v4-0005 only
delegates authority to
> 1 июля 2021 г., в 20:59, Mark Dilger
> написал(а):
>
>
>
>> On Jun 29, 2021, at 6:25 PM, Mark Dilger
>> wrote:
>>
>> Please find attached a new set of patches.
>
> And again, this time attaching a fifth patch which includes the work to allow
> users who belong to the right security
> On May 27, 2021, at 11:06 PM, Noah Misch wrote:
>
> On Tue, May 25, 2021 at 01:33:54PM -0700, Mark Dilger wrote:
>> v3-0001 adds a new pg_logical_replication role with permission to manage
>> publications and subscriptions.
>
>> v3-0004 adds a new pg_database_security role with permission
On Tue, May 25, 2021 at 01:33:54PM -0700, Mark Dilger wrote:
> v3-0001 adds a new pg_logical_replication role with permission to manage
> publications and subscriptions.
> v3-0004 adds a new pg_database_security role with permission to perform many
> actions that would otherwise require
> On May 13, 2021, at 12:18 PM, Jacob Champion wrote:
>
> On Thu, 2021-05-13 at 11:42 -0700, Mark Dilger wrote:
>> The distinction that Theme+Security would make is that capabilities
>> can be categorized by the area of the system:
>> -- planner
>> -- replication
>> -- logging
>> ...
>>
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Thu, 2021-05-13 at 11:42 -0700, Mark Dilger wrote:
> > The distinction that Theme+Security would make is that capabilities
> > can be categorized by the area of the system:
> > -- planner
> > -- replication
> > -- logging
> >
On Thu, 2021-05-13 at 11:42 -0700, Mark Dilger wrote:
> The distinction that Theme+Security would make is that capabilities
> can be categorized by the area of the system:
> -- planner
> -- replication
> -- logging
> ...
> but also by the security implications of what is being done:
> --
> On May 13, 2021, at 10:41 AM, Stephen Frost wrote:
>
> Greetings,
>
> * Mark Dilger (mark.dil...@enterprisedb.com) wrote:
>>> On May 12, 2021, at 12:58 PM, Robert Haas wrote:
>>> - Group things by which section of postgresql.conf they're in, and
>>> then further restrict some of them as
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On May 12, 2021, at 12:58 PM, Robert Haas wrote:
> > - Group things by which section of postgresql.conf they're in, and
> > then further restrict some of them as security-sensitive. This is
> > reasonably close to what you've
> On May 12, 2021, at 12:58 PM, Robert Haas wrote:
>
> - Group things by which section of postgresql.conf they're in, and
> then further restrict some of them as security-sensitive. This is
> reasonably close to what you've got, but not exactly what you've got.
> One issue is that it risks
On Wed, May 12, 2021 at 11:59 AM Mark Dilger
wrote:
> I didn't bother updating the docs yet, as I doubt the set of privileges/roles
> in this patch will survive contact with this list. They are:
>
> [ various things ]
Interesting classification. I think the trick here is going to be to
figure
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, May 3, 2021 at 2:48 PM Tom Lane wrote:
> > I'm still of the opinion that slicing and dicing this at the per-GUC
> > level is a huge waste of effort. Just invent one role that lets
> > grantees set any GUC, document it as being
On Mon, May 3, 2021 at 2:48 PM Tom Lane wrote:
> I'm still of the opinion that slicing and dicing this at the per-GUC
> level is a huge waste of effort. Just invent one role that lets
> grantees set any GUC, document it as being superuser-equivalent,
> and be done.
If you want to grant someone
On Mon, May 3, 2021 at 2:41 PM Stephen Frost wrote:
> In general, I agree that we should be looking at predefined roles as
> being similar to the Linux capabilities system- defining certain kinds
> of operations which the user who has that role is allowed to do, and
> then both in-core and
1 - 100 of 118 matches
Mail list logo
