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
36 matches
Mail list logo
