On Sun, 15 Jan 2023 at 06:02, Robert Haas wrote:
>
> On Sat, Jan 14, 2023 at 2:26 AM vignesh C wrote:
> > I'm not sure if any work is left here, if there is nothing more to do,
> > can we close this?
>
> There's a discussion on another thread about some follow-up
> documentation adjustments, but
On Sat, Jan 14, 2023 at 2:26 AM vignesh C wrote:
> I'm not sure if any work is left here, if there is nothing more to do,
> can we close this?
There's a discussion on another thread about some follow-up
documentation adjustments, but feel free to close the CF entry for
this patch.
--
Robert
On Tue, 10 Jan 2023 at 23:16, Robert Haas wrote:
>
> On Thu, Jan 5, 2023 at 2:53 PM Robert Haas wrote:
> > On Tue, Jan 3, 2023 at 3:11 PM Robert Haas wrote:
> > > Committed and back-patched 0001 with fixes for the issues that you
> > > pointed out.
> > >
> > > Here's a trivial rebase of the
On Thu, Jan 5, 2023 at 2:53 PM Robert Haas wrote:
> On Tue, Jan 3, 2023 at 3:11 PM Robert Haas wrote:
> > Committed and back-patched 0001 with fixes for the issues that you pointed
> > out.
> >
> > Here's a trivial rebase of the rest of the patch set.
>
> I committed 0001 and 0002 after
On Tue, Jan 3, 2023 at 3:11 PM Robert Haas wrote:
> Committed and back-patched 0001 with fixes for the issues that you pointed
> out.
>
> Here's a trivial rebase of the rest of the patch set.
I committed 0001 and 0002 after improving the commit messages a bit.
Here's the remaining two patches
On Fri, Dec 23, 2022 at 4:55 PM Robert Haas wrote:
> On Thu, Dec 22, 2022 at 9:14 AM Alvaro Herrera
> wrote:
> > The contents looks good to me other than that problem, and I agree to
> > backpatch it.
>
> Cool. Thanks for the review.
>
> > Why did you choose to use two dots for ellipses in some
On Thu, Dec 22, 2022 at 9:14 AM Alvaro Herrera wrote:
> The contents looks good to me other than that problem, and I agree to
> backpatch it.
Cool. Thanks for the review.
> Why did you choose to use two dots for ellipses in some command
> s rather than three? I know I've made that choice too
Reading 0001:
+However, CREATEROLE does not convey the ability to
+create SUPERUSER roles, nor does it convey any
+power over SUPERUSER roles that already exist.
+Furthermore, CREATEROLE does not convey the power
+to create REPLICATION users, nor the
On Mon, Nov 28, 2022 at 8:33 PM Robert Haas wrote:
> Hmm, that's an interesting alternative to what I actually implemented.
> Some people might like it better, because it puts the behavior fully
> under the control of the CREATEROLE user, which a number of you seem
> to favor.
Here's an updated
On Tue, Nov 29, 2022 at 2:32 AM wrote:
> I propose a slightly different syntax instead:
>
> ALTER DEFAULT PRIVILEGES GRANT CREATED ROLE TO role_specification WITH ...;
>
> This, together with the proposal above regarding the grantor, should be
> consistent.
I think that is more powerful than
On Tue, Nov 29, 2022 at 12:32 AM wrote:
>
> Is there any other argument to be made against ADP?
>
These aren't privileges, they are memberships. The pg_default_acl catalog
is also per-data while these settings should be present in a catalog which,
like pg_authid, is catalog-wide. This latter
Robert Haas:
1) Automatically install an additional membership grant, with the CREATEROLE
user as the grantor, specifying INHERIT OR SET as TRUE (I personally favor
attaching these to ALTER ROLE, modifiable only by oneself)
Hmm, that's an interesting alternative to what I actually
Robert Haas:
And the result is that I've got like five people, some of whom
particulated in those discussions, showing up to say "hey, we don't
need the ability to set defaults." Well, if that's the case, then why
did we have hundreds and hundreds of emails within the last 12 months
arguing
Mark Dilger:
Isn't this just GRANT .. WITH SET FALSE, INHERIT FALSE, ADMIN TRUE? That should
allow role administration, without actually granting membership in that role,
yet, right?
Can you clarify what you mean here? Are you inventing a new syntax?
+GRANT bob TO alice WITH SET FALSE,
On Mon, Nov 28, 2022 at 6:32 PM David G. Johnston
wrote:
> Desirable follow-on patches include:
>
> 1) Automatically install an additional membership grant, with the CREATEROLE
> user as the grantor, specifying INHERIT OR SET as TRUE (I personally favor
> attaching these to ALTER ROLE,
On Mon, Nov 28, 2022 at 4:55 PM Robert Haas wrote:
> But so far nobody has actually reviewed anything, ...
Actually this isn't true. Mark did review. Thanks, Mark.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Nov 28, 2022 at 2:55 PM Robert Haas wrote:
> On Mon, Nov 28, 2022 at 4:19 PM David G. Johnston
> wrote:
> > That's fine, but are you saying this patch is incapable (or simply
> undesirable) of having the parts about handling defaults separated out from
> the parts that define how the
On Mon, Nov 28, 2022 at 4:19 PM David G. Johnston
wrote:
> That's fine, but are you saying this patch is incapable (or simply
> undesirable) of having the parts about handling defaults separated out from
> the parts that define how the system works with a given set of permissions;
> and the
On Mon, Nov 28, 2022 at 1:28 PM Robert Haas wrote:
> On Mon, Nov 28, 2022 at 3:02 PM Mark Dilger
> wrote:
>
> You can argue that a grant with INHERIT FALSE, SET FALSE, ADMIN TRUE
> still grants membership, and I think formally that's true, but I also
> think it's just picking something to
> On Nov 28, 2022, at 12:33 PM, Mark Dilger
> wrote:
>
>> Isn't this just GRANT .. WITH SET FALSE, INHERIT FALSE, ADMIN TRUE? That
>> should allow role administration, without actually granting membership in
>> that role, yet, right?
>
> Can you clarify what you mean here? Are you
> On Nov 28, 2022, at 12:08 PM, walt...@technowledgy.de wrote:
>
> Isn't this just GRANT .. WITH SET FALSE, INHERIT FALSE, ADMIN TRUE? That
> should allow role administration, without actually granting membership in
> that role, yet, right?
Can you clarify what you mean here? Are you
On Mon, Nov 28, 2022 at 3:02 PM Mark Dilger
wrote:
> Robert's patch tries to deal with the (possibly unwanted) role membership by
> setting up defaults to mitigate the effects, but that is more confusing to me
> than just de-conflating role membership from role administration, and giving
>
Mark Dilger:
Robert's patch tries to deal with the (possibly unwanted) role membership by
setting up defaults to mitigate the effects, but that is more confusing to me
than just de-conflating role membership from role administration, and giving
role creators administration over roles they
> On Nov 28, 2022, at 11:34 AM, David G. Johnston
> wrote:
>
> No Defaults needed: David J., Mark?, Tom?
As Robert has the patch organized, I think defaults are needed, but I see that
as a strike against the patch.
> Defaults needed - attached to role directly: Robert
> Defaults needed -
Robert Haas:
In my proposal, the "object" is not the GRANT of that role. It's the
role itself. So the default privileges express what should happen when
the role is created. The default privileges would NOT affect a regular
GRANT role TO role_spec command. They only run that command when a role
On Mon, Nov 28, 2022 at 12:42 PM wrote:
> David G. Johnston:
> > A quick tally of the thread so far:
> >
> > No Defaults needed: David J., Mark?, Tom?
> > Defaults needed - attached to role directly: Robert
> > Defaults needed - defined within Default Privileges: Walther?
>
> s/Walther/Wolfgang
David G. Johnston:
A quick tally of the thread so far:
No Defaults needed: David J., Mark?, Tom?
Defaults needed - attached to role directly: Robert
Defaults needed - defined within Default Privileges: Walther?
s/Walther/Wolfgang
The capability itself seems orthogonal to the rest of the
On Mon, Nov 28, 2022 at 1:56 PM wrote:
> And now this reason is gone - there is no reason NOT to implement it as
> DEFAULT PRIVILEGES.
I think there is, and it's this, which you wrote further down:
> In my proposal, the "object" is not the GRANT of that role. It's the
> role itself. So the
On Mon, Nov 28, 2022 at 11:57 AM wrote:
> Robert Haas:
> > I don't know if changing the syntax from A to B is really getting us
> > anywhere. I generally agree that the ALTER DEFAULT PRIVILEGES syntax
> > looks nicer than the CREATE/ALTER ROLE syntax, but I'm not sure that's
> > a sufficient
Robert Haas:
I don't know if changing the syntax from A to B is really getting us
anywhere. I generally agree that the ALTER DEFAULT PRIVILEGES syntax
looks nicer than the CREATE/ALTER ROLE syntax, but I'm not sure that's
a sufficient reason to move the control over this behavior to ALTER
On Thu, Nov 24, 2022 at 2:41 AM wrote:
> INHERITCREATEDROLES and SETCREATEDROLES behave much like DEFAULT
> PRIVILEGES. What about something like:
>
> ALTER DEFAULT PRIVILEGES FOR alice
> GRANT TO alice WITH INHERIT FALSE, SET TRUE, ADMIN TRUE
>
> The "abbreviated grant" is very much abbreviated,
Robert Haas:
I have to admit that when I realized that was the natural place to put
them to make the patch work, my first reaction internally was "well,
that can't possibly be right, role properties suck!". But I didn't and
still don't see where else to put them that makes any sense at all, so
I
On Wed, Nov 23, 2022 at 4:18 PM Tom Lane wrote:
> To be clear, I'm not saying that I know a better answer. But the fact
> that these end up so different from other role-property bits seems to
> me to suggest that making them role-property bits is the wrong thing.
> They aren't privileges in any
"David G. Johnston" writes:
> On Wed, Nov 23, 2022 at 2:18 PM Robert Haas wrote:
>> Either way, I'm not quite sure what the benefit of converting these
>> things to predefined roles is.
> Specifically, you gain inheritance/set and "admin option" for free.
Right: the practical issue with
On Wed, Nov 23, 2022 at 2:18 PM Robert Haas wrote:
> On Wed, Nov 23, 2022 at 3:59 PM David G. Johnston
> wrote:
> > I haven't yet formed a complete thought here but is there any reason we
> cannot convert the permission-like attributes to predefined roles?
> >
> > pg_login
> > pg_replication
>
On Wed, Nov 23, 2022 at 2:01 PM Robert Haas wrote:
> In the latter case there are two, one with
>
> grantor=bootstrap_supeuser/admin_option=true/set_option=false/inherit_option=false
> and a second with
> grantor=alice/admin_option=false/set_option=true/inherit_option=true.
>
This, IMO, is
Robert Haas writes:
> But having said that, I could certainly change the patches so that any
> user, or maybe just a createrole user since it's otherwise irrelevant,
> can flip the INHERITCREATEDROLE and SETCREATEDROLE bits on their own
> account. There would be no harm in that from a security or
On Wed, Nov 23, 2022 at 3:59 PM David G. Johnston
wrote:
> I haven't yet formed a complete thought here but is there any reason we
> cannot convert the permission-like attributes to predefined roles?
>
> pg_login
> pg_replication
> pg_bypassrls
> pg_createdb
> pg_createrole
> pg_haspassword
On Wed, Nov 23, 2022 at 3:33 PM Tom Lane wrote:
> > Because they are role-level properties, they can be set by whoever has
> > ADMIN OPTION on the role. That always includes every superuser, and it
> > never includes Alice herself (except if she's a superuser).
>
> That is just bizarre. Alice
On Wed, Nov 23, 2022 at 1:04 PM Robert Haas wrote:
>
> I'm not very certain about any of that stuff; I don't have a clear
> mental model of how it should work, or even what exact problem we're
> trying to solve. To me, the patches that I posted make sense as far as
> they go, but I'm not under
On Wed, Nov 23, 2022 at 3:11 PM Mark Dilger
wrote:
> Ok, so the critical part of this proposal is that auditing tools can tell
> when Alice circumvents these settings. Without that bit, the whole thing is
> inane. Why make Alice jump through hoops that you are explicitly allowing
> her to
Robert Haas writes:
> On Wed, Nov 23, 2022 at 2:28 PM Mark Dilger
> wrote:
>> I had incorrectly imagined that if the bootstrap superuser granted
>> CREATEROLE to Alice with particular settings, those settings would
>> limit the things that Alice could do when creating role Bob,
>> specifically
> On Nov 23, 2022, at 12:04 PM, Robert Haas wrote:
>
>> But if that's the case, did I misunderstand upthread that these are
>> properties the superuser specifies about Alice? Can Alice just set these
>> properties about herself, so she gets the behavior she wants? I'm confused
>> now
On Wed, Nov 23, 2022 at 2:28 PM Mark Dilger
wrote:
> > On Nov 23, 2022, at 11:02 AM, Robert Haas wrote:
> > For me, this
> > clearly falls into the "good" category: it's configuration that you
> > put into the database that makes things happen the way you want, not a
> > behavior-changing
> On Nov 23, 2022, at 11:02 AM, Robert Haas wrote:
>
> For me, this
> clearly falls into the "good" category: it's configuration that you
> put into the database that makes things happen the way you want, not a
> behavior-changing setting that comes along and ruins somebody's day.
I had
On Wed, Nov 23, 2022 at 1:11 PM Tom Lane wrote:
> I haven't thought about these issues hard enough to form an overall
> opinion (though I agree that making CREATEROLE less tantamount
> to superuser would be an improvement). However, I share Mark's
> discomfort about making these commands act
Robert Haas writes:
> On Wed, Nov 23, 2022 at 12:36 PM Mark Dilger
> wrote:
>> Yes, this all makes sense, but does it entail that the CREATE ROLE command
>> must behave differently on the basis of a setting?
> Well, we certainly don't HAVE to add those new role-level properties;
> that's why
On Wed, Nov 23, 2022 at 12:36 PM Mark Dilger
wrote:
> Oh, I don't mean that it will be poorly documented. I mean that the way the
> command is written won't advertise what it is going to do. That's concerning
> if you fat-finger a CREATE ROLE command, then realize you need to drop and
>
> On Nov 23, 2022, at 9:01 AM, Robert Haas wrote:
>
>> That's not to say that I wouldn't rather that it always work one way or
>> always the other. It's just to say that I don't want it to work differently
>> based on some poorly advertised property of the role executing the command.
>
>
On Tue, Nov 22, 2022 at 5:48 PM Mark Dilger
wrote:
> Whatever behavior is to happen in the CREATE ROLE statement should be spelled
> out in that statement. "CREATE ROLE bob WITH INHERIT false WITH SET false"
> doesn't seem too unwieldy, and has the merit that it can be read and
> understood
> On Nov 22, 2022, at 2:02 PM, Robert Haas wrote:
>
>> Patch 0004 feels like something that won't get committed. The
>> INHERITCREATEDROLES and SETCREATEDROLES in 0004 seems clunky.
>
> I think role properties are kind of clunky in general, the way we've
> implemented them in PostgreSQL,
On Tue, Nov 22, 2022 at 3:01 PM Mark Dilger
wrote:
> > On Nov 21, 2022, at 12:39 PM, Robert Haas wrote:
> > I have drafted a few patches to try to improve the situation.
>
> The 0001 and 0002 patches appear to be uncontroversial refactorings. Patch
> 0003 looks on-point and a move in the right
> On Nov 21, 2022, at 12:39 PM, Robert Haas wrote:
>
> I have drafted a few patches to try to improve the situation.
The 0001 and 0002 patches appear to be uncontroversial refactorings. Patch
0003 looks on-point and a move in the right direction. The commit message in
that patch is well
On 11/21/22 15:39, Robert Haas wrote:
I'm curious to hear what other people think of these proposals, but
let me first say what I think about them. First, I think it's clear
that we need to do something, because things right now are pretty
badly broken and in a way that affects security.
walt...@technowledgy.de writes:
>> No, we don't support partial indexes on catalogs, and I don't think
>> we want to change that. Partial indexes would require expression
>> evaluations occurring at very inopportune times.
> I see. Is that the same for indexes *on* an expression? Or would those
Wolfgang Walther:
Tom Lane:
No, we don't support partial indexes on catalogs, and I don't think
we want to change that. Partial indexes would require expression
evaluations occurring at very inopportune times.
I see. Is that the same for indexes *on* an expression? Or would those
be ok?
Tom Lane:
No, we don't support partial indexes on catalogs, and I don't think
we want to change that. Partial indexes would require expression
evaluations occurring at very inopportune times.
I see. Is that the same for indexes *on* an expression? Or would those
be ok?
With a custom
walt...@technowledgy.de writes:
> Robert Haas:
>> 2. There are some serious implementation challenges because the
>> constraints on duplicate object names must be something which can be
>> enforced by unique constraints on the relevant catalogs. Off-hand, I
>> don't see how to do that.
> For each
Robert Haas:
2. There are some serious implementation challenges because the
constraints on duplicate object names must be something which can be
enforced by unique constraints on the relevant catalogs. Off-hand, I
don't see how to do that. It would be easy to make the cluster roles
all have
On Tue, Nov 22, 2022 at 3:02 AM wrote:
> My suggestion to $subject and the namespace problem would be to
> introduce database-specific roles, i.e. add a database column to
> pg_authid. Having this column set to 0 will make the role a cluster-wide
> role ("cluster role") just as currently the
Robert Haas:
It seems
to me that the root of any fix in this area must be to change the rule
that CREATEROLE can administer any role whatsoever.
Agreed.
Instead, I propose
to change things so that you can only administer roles for which you
have ADMIN OPTION. [...] > I'm curious to hear what
The CREATEROLE permission is in a very bad spot right now. The biggest
problem that I know about is that it allows you to trivially access
the OS user account under which PostgreSQL is running, which is
expected behavior for a superuser but simply wrong behavior for any
other user. This is because
62 matches
Mail list logo
