Robert Haas writes:
> On Thu, Aug 18, 2022 at 1:26 PM Robert Haas wrote:
>> CI is happier with this version, so I've committed 0001. If no major
>> problems emerge, I'll proceed with 0002 as well.
> Done.
Shouldn't the CF entry [1] be closed as committed?
regards, tom l
On Wed, Sep 7, 2022 at 10:56 AM Jeff Davis wrote:
> OK. I suppose the best path forward is to just try to improve the
> ability to administer the system without relying as much on superusers,
> which will allow us to safely ignore some of the weirdness caused by
> superusers issuing grants.
Yeah,
On Wed, 2022-09-07 at 09:39 -0400, Robert Haas wrote:
> Now that is not to say that we couldn't decide that
> select_best_grantor() got it wrong and choose to break backward
> compatibility in order to fix it ... but I'm not even convinced that
> the alternative behavior you propose is clearly bett
On Tue, Sep 6, 2022 at 7:26 PM Jeff Davis wrote:
> There's at least one other difference: if you specify "GRANTED BY su1"
> for a table grant, it still selects the table owner as the grantor;
> whereas if you specify "GRANTED BY su1" for a role grant, it selects
> "su1".
Right. Personally, I'm in
On Tue, 2022-09-06 at 16:26 -0700, Jeff Davis wrote:
> In other words, omitting
> GRANTED BY is the same as specifying "GRANTED BY current_user".
Let me correct this thinko to distinguish between specifying GRANTED BY
and not:
* Let the granting user be the one specified in the GRANTED BY claus
On Tue, 2022-09-06 at 13:15 -0400, Robert Haas wrote:
> Like, the logic to infer the grantor in check_role_grantor() and
> select_best_admin() is intended to be, and as far as I know actually
> is, an exact clone of the logic in select_best_grantor(). It is
> different only in that we regard the
On Fri, Sep 2, 2022 at 6:01 PM Jeff Davis wrote:
> > Yes. I figured that, when GRANTED BY is not specified, it is OK to
> > infer a valid grantor
>
> The spec is clear that the grantor should be either the current user or
> the current role. We also have a concept of INHERIT, which allows us to
>
On Fri, 2022-09-02 at 09:30 -0400, Robert Haas wrote:
> Thanks for having a look.
Thanks for doing the work.
> Yes. I figured that, when GRANTED BY is not specified, it is OK to
> infer a valid grantor
The spec is clear that the grantor should be either the current user or
the current role. We a
Thanks for having a look.
On Thu, Sep 1, 2022 at 4:34 PM Jeff Davis wrote:
> There's still some weirdness around superusers:
>
> 1. "GRANTED BY current_user" differs from not specifying "GRANTED BY"
> at all.
Yes. I figured that, when GRANTED BY is not specified, it is OK to
infer a valid granto
On Mon, 2022-08-22 at 11:47 -0400, Robert Haas wrote:
> On Thu, Aug 18, 2022 at 1:26 PM Robert Haas
> wrote:
> > On Wed, Aug 10, 2022 at 4:28 PM Robert Haas
> > wrote:
> > > Well, CI isn't happy with this, and for good reason:
> >
> > CI is happier with this version, so I've committed 0001. If n
On Thu, Aug 18, 2022 at 1:26 PM Robert Haas wrote:
> On Wed, Aug 10, 2022 at 4:28 PM Robert Haas wrote:
> > Well, CI isn't happy with this, and for good reason:
>
> CI is happier with this version, so I've committed 0001. If no major
> problems emerge, I'll proceed with 0002 as well.
Done.
--
R
On Wed, Aug 10, 2022 at 4:28 PM Robert Haas wrote:
> Well, CI isn't happy with this, and for good reason:
CI is happier with this version, so I've committed 0001. If no major
problems emerge, I'll proceed with 0002 as well.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Aug 1, 2022 at 3:51 PM Robert Haas wrote:
> On Mon, Aug 1, 2022 at 1:38 PM Tom Lane wrote:
> >> I think the latter --- the cfbot thinks the July CF is no longer relevant,
> > but Jacob hasn't yet moved your patches forward. You could wait for
> > him to do that, or do it yourself.
>
> Do
On Mon, Aug 1, 2022 at 10:38 AM Tom Lane wrote:
> > I can't see this on cfbot - either I don't know how to use it
> > properly, which is quite possible, or the results aren't showing up
> > because of the close of the July CommitFest.
>
> I think the latter --- the cfbot thinks the July CF is no l
On Mon, Aug 1, 2022 at 1:38 PM Tom Lane wrote:
>> I think the latter --- the cfbot thinks the July CF is no longer relevant,
> but Jacob hasn't yet moved your patches forward. You could wait for
> him to do that, or do it yourself.
Done. New patches attached.
Changes in v4, for 0001:
- Typo fi
Robert Haas writes:
> On Sun, Jul 31, 2022 at 2:34 PM Tom Lane wrote:
>> Indeed. I've not read the patch, but I just wanted to mention that
>> the cfbot shows it as failing regression tests on all platforms.
>> Possibly a conflict with some recent commit?
> I can't see this on cfbot - either I
On Sun, Jul 31, 2022 at 2:34 PM Tom Lane wrote:
> Indeed. I've not read the patch, but I just wanted to mention that
> the cfbot shows it as failing regression tests on all platforms.
> Possibly a conflict with some recent commit?
I can't see this on cfbot - either I don't know how to use it
pro
On Sun, Jul 31, 2022 at 2:18 PM Stephen Frost wrote:
> Thanks for working on this.
Thanks for the review.
> > Previously, only the superuser could specify GRANTED BY with a user
> > other than the current user. Relax that rule to allow the grantor
> > to be any role whose privileges the current
Greetings,
On Sun, Jul 31, 2022 at 11:44 David G. Johnston
wrote:
> On Sun, Jul 31, 2022 at 11:18 AM Stephen Frost wrote:
>
>> Greetings,
>>
>> * Robert Haas (robertmh...@gmail.com) wrote:
>> > On Tue, Jul 26, 2022 at 12:46 PM Robert Haas
>> wrote:
>>
>> + }
>> +
>> + /*
>> +
On Sun, Jul 31, 2022 at 11:18 AM Stephen Frost wrote:
> Greetings,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Tue, Jul 26, 2022 at 12:46 PM Robert Haas
> wrote:
>
> + }
> +
> + /*
> +* Disallow attempts to grant ADMIN OPTION back to a user who
> granted it
> +
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> OK, so I fixed that, and also updated the documentation a bit more. I
>> think these patches are basically done, and I'd like to get them
>> committed before too much more time goes by, because I have other
>> things that depe
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jul 26, 2022 at 12:46 PM Robert Haas wrote:
> > I believe that these patches are mostly complete, but I think that
> > dumpRoleMembership() probably needs some more work. I don't know what
> > exactly, but there's nothing to cause
On Thu, Jul 28, 2022 at 5:17 PM David G. Johnston
wrote:
> I suggest changing \du memberof to output something like this:
>
> rolname | memberof
> -+
> vagrant | {}
> r | {q:admin/vagrant}
> t | {q:admin/vagrant,s:member/vagr
On Thu, Jul 28, 2022 at 12:09 PM Robert Haas wrote:
> On Tue, Jul 26, 2022 at 12:46 PM Robert Haas
> wrote:
> > I believe that these patches are mostly complete, but I think that
> > dumpRoleMembership() probably needs some more work. I don't know what
> > exactly, but there's nothing to cause i
On Tue, Jul 26, 2022 at 12:46 PM Robert Haas wrote:
> I believe that these patches are mostly complete, but I think that
> dumpRoleMembership() probably needs some more work. I don't know what
> exactly, but there's nothing to cause it to dump the role grants in an
> order that will create depende
On Wed, Jul 20, 2022 at 3:11 PM Robert Haas wrote:
> The previous version of the patch makes both DROP OWNED and REASSIGN
> OWNED cascade to grantors, but I now think that, for consistency, I'd
> better look into changing it so that only DROP OWNED cascades. I think
> perhaps I should be using SHA
On Fri, Jun 24, 2022 at 4:46 PM Robert Haas wrote:
> On Fri, Jun 24, 2022 at 4:30 PM David G. Johnston
> wrote:
> >> Upthread, I proposed that "drop role baz" should fail here
> >
> > I concur with this.
> >
> > I think that the grantor owns the grant, and that REASSIGNED OWNED should
> > be abl
On Fri, Jun 24, 2022 at 4:46 PM Robert Haas wrote:
> Interesting. I hadn't thought about changing the behavior of DROP
> OWNED BY and REASSIGN OWNED BY. A quick experiment supports your
> interpretation:
Here is a minimal patch fixing exactly $SUBJECT. Granting a role to
another role now creates
On Fri, Jun 24, 2022 at 4:30 PM David G. Johnston
wrote:
>> Upthread, I proposed that "drop role baz" should fail here
>
> I concur with this.
>
> I think that the grantor owns the grant, and that REASSIGNED OWNED should be
> able to move those grants to someone else.
>
> By extension, DROP OWNED
On Fri, Jun 24, 2022 at 1:19 PM Robert Haas wrote:
> On Mon, Jun 6, 2022 at 7:41 PM Stephen Frost wrote:
> >
> > In terms of how that's then used, yeah, it's during REVOKE because a
> > REVOKE is only able to 'find' role authorization descriptors which match
> > the triple of role revoked, grant
On Mon, Jun 6, 2022 at 7:41 PM Stephen Frost wrote:
> Thankfully, at least from my reading, the spec isn't all that
> complicated on this particular point. The spec talks about "role
> authorization descriptor"s and those are "created with role name,
> grantee, and grantor" and then further says
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jun 2, 2022 at 3:51 PM Tom Lane wrote:
> > > I sort of thought http://postgr.es/m/3981966.1646429...@sss.pgh.pa.us
> > > constituted a completed investigation of this sort. No?
> >
> > I didn't think so. It's clear that the spec e
On Thu, Jun 2, 2022 at 3:51 PM Tom Lane wrote:
> > I sort of thought http://postgr.es/m/3981966.1646429...@sss.pgh.pa.us
> > constituted a completed investigation of this sort. No?
>
> I didn't think so. It's clear that the spec expects us to track the
> grantor, but I didn't chase down what it e
Robert Haas writes:
> On Thu, Jun 2, 2022 at 3:15 PM Tom Lane wrote:
>> Maybe. What I was pointing out is that this is SQL-standard syntax
>> and there are SQL-standard semantics that it ought to be implementing.
>> Probably those semantics match what you describe here, but we ought
>> to dive i
On Thu, Jun 2, 2022 at 3:15 PM Tom Lane wrote:
> Maybe. What I was pointing out is that this is SQL-standard syntax
> and there are SQL-standard semantics that it ought to be implementing.
> Probably those semantics match what you describe here, but we ought
> to dive into the spec and make sure
Robert Haas writes:
> On Fri, Mar 4, 2022 at 4:34 PM Tom Lane wrote:
>> If we are not tracking the grantors of role authorizations,
>> then we are doing it wrong and we ought to fix that.
> So let's talk about how we could fix this. In a vacuum I'd say this is
> just a feature that never got fin
On Fri, Mar 4, 2022 at 4:34 PM Tom Lane wrote:
> If we are not tracking the grantors of role authorizations,
> then we are doing it wrong and we ought to fix that.
We are definitely doing it wrong. It's not that we aren't doing it at
all, but we are doing it incorrectly. If user foo executes "GRA
37 matches
Mail list logo
