On Thu, Aug 25, 2022 at 10:19:39AM -0400, Robert Haas wrote:
> I read through this again and found a comment that needed to be
> updated, so I did that, bumped catversion, and committed this.
[commit e3ce2de]
> @@ -4735,8 +4735,8 @@ initialize_acl(void)
>
> /*
>* I
Hello,
Thanks for reviewing. Committed.
Let me return to this topic.
After looking at the changes in this patch, I have a suggestion.
The inheritance option for role memberships is important information to
know if the role privileges will be available automatically or if a
switch with a SE
On Tue, Aug 30, 2022 at 6:10 PM Nathan Bossart wrote:
> On Tue, Aug 30, 2022 at 08:33:46AM -0400, Robert Haas wrote:
> > Third try.
>
> Now that I have this grantor stuff fresh in my mind, this patch looks good
> to me.
Thanks for reviewing. Committed.
--
Robert Haas
EDB: http://www.enterprised
On Tue, Aug 30, 2022 at 5:20 PM Nathan Bossart wrote:
> On Tue, Aug 30, 2022 at 03:24:56PM -0400, Robert Haas wrote:
> > - william => charles => elizabeth => uk is OK because the first two
> > hops have ADMIN and the last hop has INHERIT
>
> Don't you mean the first two hops have INHERIT and the l
On Tue, Aug 30, 2022 at 08:33:46AM -0400, Robert Haas wrote:
> Third try.
Now that I have this grantor stuff fresh in my mind, this patch looks good
to me.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Aug 30, 2022 at 03:24:56PM -0400, Robert Haas wrote:
> - william => charles => elizabeth => uk is OK because the first two
> hops have ADMIN and the last hop has INHERIT
Don't you mean the first two hops have INHERIT and the last has ADMIN?
> - william => charles => elizabeth => uk => par
On Tue, Aug 30, 2022 at 1:30 PM Nathan Bossart wrote:
> I've been staring at this stuff for a while, and I'm still rather confused.
>
> * You mention that you modelled the "new" function select_best_grantor() on
> is_admin_of_role(), but it looks like that function was introduced in 2005.
> IIUC y
On Mon, Aug 29, 2022 at 03:38:57PM -0400, Robert Haas wrote:
> Argh, I found a bug, and one that I should have caught during testing,
> too. I modelled the new function select_best_grantor() on
> is_admin_of_role(), but it differs in that it calls
> roles_is_member_of() with ROLERECURSE_PRIVS rathe
On Tue, Aug 30, 2022 at 8:24 AM Robert Haas wrote:
> On Mon, Aug 29, 2022 at 10:16 PM Robert Haas wrote:
> > I'll figure out a fix tomorrow when I'm less tired. Thanks for catching it.
>
> Second try.
Third try.
--
Robert Haas
EDB: http://www.enterprisedb.com
v3-0001-Fix-a-bug-in-roles_is_me
On Mon, Aug 29, 2022 at 10:16 PM Robert Haas wrote:
> I'll figure out a fix tomorrow when I'm less tired. Thanks for catching it.
Second try.
--
Robert Haas
EDB: http://www.enterprisedb.com
v2-0001-Fix-a-bug-in-roles_is_member_of.patch
Description: Binary data
On Mon, Aug 29, 2022 at 6:04 PM Nathan Bossart wrote:
> On Mon, Aug 29, 2022 at 03:38:57PM -0400, Robert Haas wrote:
> > Here is a patch to rearrange the logic slightly and also add a test
> > case memorializing the intended behavior. Without this change, the
> > regression test included in the pa
On Mon, Aug 29, 2022 at 03:38:57PM -0400, Robert Haas wrote:
> Here is a patch to rearrange the logic slightly and also add a test
> case memorializing the intended behavior. Without this change, the
> regression test included in the patch fails like this:
>
> ERROR: no possible grantors
>
> ...
On Mon, Aug 29, 2022 at 10:17 AM Robert Haas wrote:
> Good catch. Thanks for the review. Committed with that correction.
Argh, I found a bug, and one that I should have caught during testing,
too. I modelled the new function select_best_grantor() on
is_admin_of_role(), but it differs in that it c
On Sun, Aug 28, 2022 at 5:14 PM Nathan Bossart wrote:
> nitpick: I believe there should be a period before "After."
>
> Otherwise, LGTM.
Good catch. Thanks for the review. Committed with that correction.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, Aug 26, 2022 at 02:46:59PM -0400, Robert Haas wrote:
> - membership is via admin which has the
> NOINHERIT
> - attribute. After:
> + membership is via admin which was granted using
> + WITH INHERIT FALSE After:
nitpick: I believe there should be a period before "After."
Otherwis
On Thu, Aug 25, 2022 at 10:19 AM Robert Haas wrote:
> On Wed, Aug 24, 2022 at 10:23 AM tushar wrote:
> > On 8/24/22 12:28 AM, Robert Haas wrote:
> > > This patch needed to be rebased pretty extensively after commit
> > > ce6b672e4455820a0348214be0da1a024c3f619f. Here is a new version.
> > Thanks,
On Wed, Aug 24, 2022 at 10:23 AM tushar wrote:
> On 8/24/22 12:28 AM, Robert Haas wrote:
> > This patch needed to be rebased pretty extensively after commit
> > ce6b672e4455820a0348214be0da1a024c3f619f. Here is a new version.
> Thanks, Robert, I have retested this patch with my previous scenarios
On 8/24/22 12:28 AM, Robert Haas wrote:
This patch needed to be rebased pretty extensively after commit
ce6b672e4455820a0348214be0da1a024c3f619f. Here is a new version.
Thanks, Robert, I have retested this patch with my previous scenarios
and things look good to me.
--
regards,tushar
Enterprise
On Thu, Jul 28, 2022 at 12:32 PM tushar wrote:
> On 7/28/22 8:03 PM, Robert Haas wrote:
> > No, it seems to me that's behaving as intended. REVOKE BLAH OPTION ...
> > is intended to be a way of switching an option off.
> Ok, Thanks, Robert. I tested with a couple of more scenarios like
> pg_upgrad
On 7/28/22 8:03 PM, Robert Haas wrote:
No, it seems to me that's behaving as intended. REVOKE BLAH OPTION ...
is intended to be a way of switching an option off.
Ok, Thanks, Robert. I tested with a couple of more scenarios like
pg_upgrade/pg_dumpall /grant/revoke .. with admin option/inherit
an
On Thu, Jul 28, 2022 at 10:16 AM tushar wrote:
> On 7/19/22 12:56 AM, Robert Haas wrote:
> > Another good catch. Here is v5 with a fix for that problem.
> Here is one scenario in which I have NOT granted (inherit false)
> explicitly but still revoke
> command is changing the current state
>
> post
On 7/19/22 12:56 AM, Robert Haas wrote:
Another good catch. Here is v5 with a fix for that problem.
Here is one scenario in which I have NOT granted (inherit false)
explicitly but still revoke
command is changing the current state
postgres=# create group foo;
CREATE ROLE
postgres=# create user
On 7/19/22 12:56 AM, Robert Haas wrote:
Another good catch. Here is v5 with a fix for that problem.
Thanks, the issue is fixed now.
--
regards,tushar
EnterpriseDB https://www.enterprisedb.com/
The Enterprise PostgreSQL Company
On Thu, Jul 14, 2022 at 10:53 AM tushar wrote:
> GRANT "g2" TO "u1" WITH GRANTED BY "edb";
Another good catch. Here is v5 with a fix for that problem.
--
Robert Haas
EDB: http://www.enterprisedb.com
v5-0001-Allow-grant-level-control-of-role-inheritance-beh.patch
Description: Binary data
On 7/11/22 11:01 PM, Robert Haas wrote:
Oops. Here is a rebased version of v3 which aims to fix this bug.
I found one issue where pg_upgrade is failing
PG v14.4 , create these below objects
create user u1 with superuser;
create user u3;
create group g2 with user u1;
now try to perform pg_upg
On 7/11/22 11:01 PM, Robert Haas wrote:
Oops. Here is a rebased version of v3 which aims to fix this bug.
Thanks, Issue seems to be fixed with this patch.
--
regards,tushar
EnterpriseDB https://www.enterprisedb.com/
The Enterprise PostgreSQL Company
On Mon, Jul 11, 2022 at 12:48 PM tushar wrote:
> One scenario where the syntax is created in pg_dumpall is wrong
>
> postgres=# create user u1;
> postgres=# create group g1 with user u1;
> postgres=# grant g1 to u1 with admin option, inherit false;
>
> Perform pg_dumpall
>
> GRANT g1 TO u1 WITH AD
On Sat, Jul 9, 2022 at 1:27 AM Robert Haas wrote:
> On Tue, Jul 5, 2022 at 8:04 AM Robert Haas wrote:
> > On Sun, Jul 3, 2022 at 1:17 PM Nathan Bossart
> wrote:
> > > If by "bolder" you mean "mark [NO]INHERIT as
> deprecated-and-to-be-removed
> > > and begin emitting WARNINGs when it and WITH I
On Fri, Jul 8, 2022 at 5:02 PM Nathan Bossart wrote:
> I think this is an interesting approach, as it seems to move things closer
> to the end goal (i.e., removing [NO]INHERIT), but it also introduces a
> pretty significant compatibility break. With this change, you cannot keep
> using [NO]INHERI
On Fri, Jul 08, 2022 at 03:56:56PM -0400, Robert Haas wrote:
> For those who may not have read the entire thread, the current patch
> does not actually remove the role-level option as the subject line
> suggests, but rather makes it set the default for future grants as
> suggested by Tom in
> http:
On Tue, Jul 5, 2022 at 8:04 AM Robert Haas wrote:
> On Sun, Jul 3, 2022 at 1:17 PM Nathan Bossart
> wrote:
> > If by "bolder" you mean "mark [NO]INHERIT as deprecated-and-to-be-removed
> > and begin emitting WARNINGs when it and WITH INHERIT DEFAULT are used," I
> > think it's worth consideratio
On Sun, Jul 3, 2022 at 1:17 PM Nathan Bossart wrote:
> If by "bolder" you mean "mark [NO]INHERIT as deprecated-and-to-be-removed
> and begin emitting WARNINGs when it and WITH INHERIT DEFAULT are used," I
> think it's worth consideration. I suspect it will be hard to sell removing
> [NO]INHERIT i
On Sat, Jul 02, 2022 at 11:04:28PM -0400, Robert Haas wrote:
> On Sat, Jul 2, 2022 at 6:16 PM Nathan Bossart
> wrote:
>> I was thinking that when DEFAULT was removed, pg_dump would just need to
>> generate WITH INHERIT TRUE/FALSE based on the value of rolinherit for older
>> versions. Using the
On Sat, Jul 2, 2022 at 6:16 PM Nathan Bossart wrote:
> I was thinking that when DEFAULT was removed, pg_dump would just need to
> generate WITH INHERIT TRUE/FALSE based on the value of rolinherit for older
> versions. Using the role-level property as the default for future grants
> seems a viable
On Sat, Jul 02, 2022 at 08:45:50AM -0400, Robert Haas wrote:
> I don't think there is a whole lot of point in replacing role-level
> flags with predefined roles that work exactly the same way. Maybe
> there is some point, but I'm not excited about it. The problem with
> these settings in my opinion
On Fri, Jul 1, 2022 at 5:12 PM Nathan Bossart wrote:
> > I have some hesitations about this approach. On the positive side, I
> > believe it's fully backward compatible, and that's something to like.
> > On the negative side, I've always felt that the role-level properties
> > - [NO]INHERIT, [NO]C
On Fri, Jul 01, 2022 at 02:59:53PM -0400, Robert Haas wrote:
> And here is a patch that makes it work that way. In this version, you
> can GRANT foo TO bar WITH INHERIT { TRUE | FALSE | DEFAULT }, and
> DEFAULT means that role-level [NO]INHERIT property is controlling.
> Otherwise, the grant-level
On Fri, Jul 1, 2022 at 9:05 AM Robert Haas wrote:
> > So now A has implicit inherited privs for t1 but not for t2.
>
> Yeah, I anticipate that this would work in the way that you postulate here.
And here is a patch that makes it work that way. In this version, you
can GRANT foo TO bar WITH INHERI
On Fri, Jul 1, 2022 at 8:22 AM Joe Conway wrote:
> Hmm, maybe I am misunderstanding something, but what I mean is something
> like:
>
> 8<
> CREATE TABLE t1(f1 int);
> CREATE TABLE t2(f1 int);
>
> CREATE USER A; --defaults to INHERIT
> CREATE USER B;
> CREATE USER C;
>
> GRANT sele
On 7/1/22 07:48, Robert Haas wrote:
On Fri, Jul 1, 2022 at 6:17 AM Joe Conway wrote:
Would this allow for an explicit REVOKE to override a default INHERIT
along a specific path?
Can you give an example?
If you mean that A is granted to B which is granted to C which is
granted to D and you no
On Fri, Jul 1, 2022 at 6:17 AM Joe Conway wrote:
> Would this allow for an explicit REVOKE to override a default INHERIT
> along a specific path?
Can you give an example?
If you mean that A is granted to B which is granted to C which is
granted to D and you now want NOINHERIT behavior for the B-
On 6/30/22 22:58, Nathan Bossart wrote:
On Thu, Jun 30, 2022 at 10:21:53PM -0400, Robert Haas wrote:
On Thu, Jun 30, 2022 at 7:29 PM Nathan Bossart wrote:
IIUC you are suggesting that we'd leave rolinherit in pg_authid alone, but
we'd add the ability to specify a grant-level option that would
On Thu, Jun 30, 2022 at 10:21:53PM -0400, Robert Haas wrote:
> On Thu, Jun 30, 2022 at 7:29 PM Nathan Bossart
> wrote:
>> IIUC you are suggesting that we'd leave rolinherit in pg_authid alone, but
>> we'd add the ability to specify a grant-level option that would always take
>> precedence. The d
On Thu, Jun 30, 2022 at 7:29 PM Nathan Bossart wrote:
> IIUC you are suggesting that we'd leave rolinherit in pg_authid alone, but
> we'd add the ability to specify a grant-level option that would always take
> precedence. The default (WITH INHERIT DEFAULT) would cause things to work
> exactly as
On Thu, Jun 30, 2022 at 09:42:11AM -0400, Robert Haas wrote:
> On Wed, Jun 29, 2022 at 7:19 PM Nathan Bossart
> wrote:
>> I'm guessing we'll also need a new pg_dumpall option for generating pre-v16
>> style role commands versus the v16+ style ones. When run on v16 and later,
>> you'd have to req
On Wed, Jun 29, 2022 at 7:19 PM Nathan Bossart wrote:
> > Here's a rather small patch that does it the first way.
>
> I've been thinking about whether we ought to WARNING or ERROR with the
> deprecated syntax. WARNING has the advantage of not breaking existing
> scripts, but users might not catch
On Wed, Jun 22, 2022 at 04:30:36PM -0400, Robert Haas wrote:
> On Thu, Jun 2, 2022 at 1:17 PM Tom Lane wrote:
>> Point 2 would cause every existing pg_dumpall script to fail, which
>> seems like kind of a large gotcha. Less unpleasant alternatives
>> could include
>>
>> * Continue to accept the s
On Thu, Jun 2, 2022 at 1:17 PM Tom Lane wrote:
> Point 2 would cause every existing pg_dumpall script to fail, which
> seems like kind of a large gotcha. Less unpleasant alternatives
> could include
>
> * Continue to accept the syntax, but ignore it, maybe with a WARNING
> for the alternative tha
On Wed, Jun 15, 2022 at 5:23 AM Peter Eisentraut
wrote:
> > Consider a user who in general prefers the NOINHERIT behavior but also
> > wants to use predefined roles. Perhaps user 'peter' is to be granted
> > both 'paul' and 'pg_execute_server_programs'. If role 'peter' is set
> > to INHERIT, Peter
On 13.06.22 20:00, Robert Haas wrote:
I don't think this creates any more of a conflict than we've already
got. In fact, I'd go so far as to say it resolves a problem that we
currently have. As far as I can see, we are stuck with a situation
where we have to support both the INHERIT behavior and
On Mon, Jun 13, 2022 at 2:42 PM David G. Johnston
wrote:
> Agreed. Moving the inherit flag to the many-to-many join relation provides
> flexibility, while representing the present behavior is trivial - every row
> for a given member role has the same value for said flag.
Precisely.
> One seem
On Mon, Jun 13, 2022 at 11:01 AM Robert Haas wrote:
> Some
>
syntax would be a bit different on the new releases and that would
> unlock some new options we don't currently have, but there's no
> behavior that you can get today which you wouldn't be able to get any
> more under this proposal.
>
On Fri, Jun 10, 2022 at 4:36 PM Peter Eisentraut
wrote:
> I think this would create a conflict with what role-based access control
> normally means (outside of PostgreSQL specifically). A role is a
> collection of privileges that you dynamically enable (e.g., with SET
> ROLE). That corresponds t
Greetings,
On Fri, Jun 10, 2022 at 16:36 Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 02.06.22 18:26, Robert Haas wrote:
> > On Mon, Feb 7, 2022 at 11:13 AM Joe Conway wrote:
> >>> It seems to me that the INHERIT role flag isn't very well-considered.
> >>> Inheritance, or th
On 02.06.22 18:26, Robert Haas wrote:
On Mon, Feb 7, 2022 at 11:13 AM Joe Conway wrote:
It seems to me that the INHERIT role flag isn't very well-considered.
Inheritance, or the lack of it, ought to be decided separately for
each inherited role. However, that would be a major architectural
chan
On Wed, Jun 8, 2022 at 10:16 AM Stephen Frost wrote:
> > That's why I proposed the name SET, not MEMBERSHIP. You would still
> > get a catalog entry in pg_auth_members, so you are still a member in
> > some loose sense even if your grant has INHERIT FALSE and SET FALSE,
> > but in such a case the
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jun 6, 2022 at 7:21 PM Stephen Frost wrote:
> > > To revoke a grant entirely, you just say REVOKE foo FROM bar, as now.
> > > To change an option for an existing grant, you can re-execute the
> > > grant statement with a different
[ trimming various comments that broadly make sense to me and which
don't seem to require further comment in this moment ]
On Mon, Jun 6, 2022 at 7:21 PM Stephen Frost wrote:
> > To revoke a grant entirely, you just say REVOKE foo FROM bar, as now.
> > To change an option for an existing grant, y
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Feb 7, 2022 at 11:13 AM Joe Conway wrote:
> > > It seems to me that the INHERIT role flag isn't very well-considered.
> > > Inheritance, or the lack of it, ought to be decided separately for
> > > each inherited role. However, that
On Thu, Jun 2, 2022 at 12:26 PM Robert Haas wrote:
> 1. Extend the GRANT role_name TO role_name [ WITH ADMIN OPTION ] with
> a new, optional clause, something like WITH NO INHERIT or WITH
> NOINHERIT or WITHOUT INHERIT.
I just realized that, with ADMIN OPTION, you can change your mind
after the i
On 2022-06-02 Th 14:06, Robert Haas wrote:
> On Thu, Jun 2, 2022 at 1:17 PM Tom Lane wrote:
>> Point 2 would cause every existing pg_dumpall script to fail, which
>> seems like kind of a large gotcha. Less unpleasant alternatives
>> could include
>>
>> * Continue to accept the syntax, but ignor
On Thu, Jun 02, 2022 at 03:37:34PM -0400, Robert Haas wrote:
> On Thu, Jun 2, 2022 at 2:07 PM Nathan Bossart
> wrote:
>> I think we should also consider replacing role attributes with predefined
>> roles. I'm not sure that this proposal totally prepares us for such a
>> change, given role attrib
On Thu, Jun 2, 2022 at 2:07 PM Nathan Bossart wrote:
> I think we should also consider replacing role attributes with predefined
> roles. I'm not sure that this proposal totally prepares us for such a
> change, given role attributes apply only to the specific role for which
> they are set and are
On Thu, Jun 02, 2022 at 12:26:48PM -0400, Robert Haas wrote:
> On Mon, Feb 7, 2022 at 11:13 AM Joe Conway wrote:
>> > It seems to me that the INHERIT role flag isn't very well-considered.
>> > Inheritance, or the lack of it, ought to be decided separately for
>> > each inherited role. However, tha
On Thu, Jun 2, 2022 at 1:17 PM Tom Lane wrote:
> Point 2 would cause every existing pg_dumpall script to fail, which
> seems like kind of a large gotcha. Less unpleasant alternatives
> could include
>
> * Continue to accept the syntax, but ignore it, maybe with a WARNING
> for the alternative tha
Robert Haas writes:
> Is this a kind of change people would support? Here's a quick sketch:
> 1. Extend the GRANT role_name TO role_name [ WITH ADMIN OPTION ] with
> a new, optional clause, something like WITH NO INHERIT or WITH
> NOINHERIT or WITHOUT INHERIT.
> 2. Remove the INHERIT | NOINHERIT
On Mon, Feb 7, 2022 at 11:13 AM Joe Conway wrote:
> > It seems to me that the INHERIT role flag isn't very well-considered.
> > Inheritance, or the lack of it, ought to be decided separately for
> > each inherited role. However, that would be a major architectural
> > change.
>
> Agreed -- that wo
67 matches
Mail list logo
