On Mon, Mar 28, 2022 at 10:51 AM Stephen Frost wrote:
> > > > So I propose to commit something like what I posted here:
> > > > http://postgr.es/m/ca+tgmobgek0jraowqvpqhsxcfbdfitxsomoebhmmmhmj4gl...@mail.gmail.com
> > >
> > > +1, although the comments might need some more work. In particular,
> >
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Mar 24, 2022 at 1:10 PM Tom Lane wrote:
> > > However, it might. And if it does, I think it would be best if
> > > removing that exception were the *only* change in this area made by
> > > that release.
> >
> > Good idea, especiall
On Thu, Mar 24, 2022 at 1:10 PM Tom Lane wrote:
> > However, it might. And if it does, I think it would be best if
> > removing that exception were the *only* change in this area made by
> > that release.
>
> Good idea, especially since it's getting to be too late to consider
> anything more invas
Robert Haas writes:
> Notwithstanding the lack of agreement on that point, I believe that
> what we should do for v15 is remove the session user
> self-administration exception. We have pretty much established that it
> was originally introduced in error.
Agreed.
> However, it might. And if it d
On Fri, Mar 11, 2022 at 11:51 AM Robert Haas wrote:
> On Fri, Mar 11, 2022 at 11:34 AM Tom Lane wrote:
> > Note that either case would also involve making entries in pg_shdepend;
> > although for the case of roles owned by/granted to the bootstrap
> > superuser, we could omit those on the usual g
> On Mar 14, 2022, at 7:38 AM, Stephen Frost wrote:
>
> So ... do you feel like that's now the case? Or were you looking for
> more?
I don't have any more questions at the moment. Thanks!
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Mar 11, 2022, at 4:56 PM, Stephen Frost wrote:
> > First … I outlined a fair bit of further description in the message you
> > just responded to but neglected to include in your response, which strikes
> > me as odd that you’
> On Mar 11, 2022, at 4:56 PM, Stephen Frost wrote:
>
> First … I outlined a fair bit of further description in the message you just
> responded to but neglected to include in your response, which strikes me as
> odd that you’re now asking for further explanation.
> When it comes to comp
Greetings,
On Fri, Mar 11, 2022 at 19:03 Mark Dilger
wrote:
> > On Mar 11, 2022, at 2:46 PM, Stephen Frost wrote:
> >
> > I do think that’s reasonable … and believe I suggested it about 3
> messages ago in this thread. ;) (step #3 I think it was? Or maybe 4).
>
> Yes, and you mentioned it to
> On Mar 11, 2022, at 2:46 PM, Stephen Frost wrote:
>
> I do think that’s reasonable … and believe I suggested it about 3 messages
> ago in this thread. ;) (step #3 I think it was? Or maybe 4).
Yes, and you mentioned it to me off-list.
I'm soliciting a more concrete specification for what
Greetings,
On Fri, Mar 11, 2022 at 12:32 Mark Dilger
wrote:
>
>
> > On Mar 11, 2022, at 8:48 AM, Stephen Frost wrote:
> >
> > I agree that it would have an impact on backwards compatibility to
> > change how WITH ADMIN works- but it would also get us more in line with
> > what the SQL standard
> On Mar 11, 2022, at 8:48 AM, Stephen Frost wrote:
>
> I agree that it would have an impact on backwards compatibility to
> change how WITH ADMIN works- but it would also get us more in line with
> what the SQL standard says for how WITH ADMIN is supposed to work and
> that seems worth the ch
On Fri, Mar 11, 2022 at 11:34 AM Tom Lane wrote:
> Note that either case would also involve making entries in pg_shdepend;
> although for the case of roles owned by/granted to the bootstrap
> superuser, we could omit those on the usual grounds that we don't need
> to record dependencies on pinned
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Mar 11, 2022 at 11:12 AM Mark Dilger
> wrote:
> > This issue of how much backwards compatibility breakage we're willing to
> > tolerate is just as important as questions about how we would want roles to
> > work in a green-field
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > If we implement the link between the creating role and the created
> > role as role ownership, then we are surely just going to add a
> > rolowner column to pg_authid, and when the role is owned by nobody, I
> > think we
On Fri, Mar 11, 2022 at 11:12 AM Mark Dilger
wrote:
> This issue of how much backwards compatibility breakage we're willing to
> tolerate is just as important as questions about how we would want roles to
> work in a green-field development project. The sense I got a year ago, on
> this list,
Robert Haas writes:
> If we implement the link between the creating role and the created
> role as role ownership, then we are surely just going to add a
> rolowner column to pg_authid, and when the role is owned by nobody, I
> think we should always just store a valid OID in it, rather than
> som
On Fri, Mar 11, 2022 at 10:46 AM Tom Lane wrote:
> The bootstrap superuser clearly must be a special case in some way.
> I'm not convinced that that means there should be other special
> cases. Maybe there is a use-case for other "unowned" roles, but in
> exactly what way would that be different
> On Mar 11, 2022, at 7:58 AM, Robert Haas wrote:
>
> This kind of thing is always a judgement call. If we were talking
> about breaking 'SELECT * from table', I'm sure it would be hard to
> convince anybody to agree to do that at all, let alone with no
> deprecation period. Fortunately, CREAT
On Fri, Mar 11, 2022 at 10:37 AM David G. Johnston
wrote:
> I largely agree and am perfectly fine with going with the majority on this
> point. My vote would just fall on the conservative side. But as so far no
> one else seems to be overly concerned, nerfing CREATEROLE seems to be the
> path
Robert Haas writes:
> On Fri, Mar 11, 2022 at 10:27 AM Stephen Frost wrote:
>> I agree that there would be a recorded relationship (that is, one that
>> we write into the catalog and keep around until and unless it's removed
>> by an admin) between creating and created roles and that's probably t
On Fri, Mar 11, 2022 at 10:27 AM Stephen Frost wrote:
> I agree that there would be a recorded relationship (that is, one that
> we write into the catalog and keep around until and unless it's removed
> by an admin) between creating and created roles and that's probably the
> default when CREATE R
On Fri, Mar 11, 2022 at 8:32 AM Stephen Frost wrote:
>
> Such scripts as will break will still
> break in a pretty clear way with a clear answer as to how to fix them
> and I don't think there's some kind of data corruption or something that
> would happen.
>
>
I largely agree and am perfectly fi
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Thu, Mar 10, 2022 at 3:01 PM Robert Haas wrote:
>
> > On Thu, Mar 10, 2022 at 4:00 PM David G. Johnston
> > wrote:
> > > I dislike changing the documented behavior of CREATEROLE to the degree
> > suggested here. However, t
On Fri, Mar 11, 2022 at 6:55 AM Robert Haas wrote:
> On Thu, Mar 10, 2022 at 5:14 PM Tom Lane wrote:
> > This seems reasonable in isolation, but
> >
> > (1) it implies a persistent relationship between creating and created
> > roles. Whether you want to call that ownership or not, it sure walks
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Mar 10, 2022 at 5:14 PM Tom Lane wrote:
> > This seems reasonable in isolation, but
> >
> > (1) it implies a persistent relationship between creating and created
> > roles. Whether you want to call that ownership or not, it sure w
On Thu, Mar 10, 2022 at 5:14 PM Tom Lane wrote:
> This seems reasonable in isolation, but
>
> (1) it implies a persistent relationship between creating and created
> roles. Whether you want to call that ownership or not, it sure walks
> and quacks like ownership.
I agree. It's been obvious to me
> On Mar 10, 2022, at 2:01 PM, Robert Haas wrote:
>
> It sounds like you prefer a behavior where CREATEROLE gives power over
> all non-superusers, but that seems pretty limiting to me. Why can't
> someone want to create a user with power over some users but not
> others?
I agree with Robert o
Robert Haas writes:
> Probably easier to just say it again: I want to have users that can
> create roles and then have superuser-like powers with respect to those
> roles. They can freely exercise the privileges of those roles, and
> they can do all the things that a superuser can do but only with
On Thu, Mar 10, 2022 at 3:01 PM Robert Haas wrote:
> On Thu, Mar 10, 2022 at 4:00 PM David G. Johnston
> wrote:
> > I dislike changing the documented behavior of CREATEROLE to the degree
> suggested here. However, there are three choices here, only one of which
> can be chosen:
> >
> > 1. Leave
On Thu, Mar 10, 2022 at 5:00 PM Bruce Momjian wrote:
> On Thu, Mar 10, 2022 at 02:22:05PM -0500, Robert Haas wrote:
> > I mean, I didn't design pg_hba.conf, but I think it's part of the
> > database doing a reasonable thing, not an external system doing a
> > nonsensical thing.
>
> FYI, I think pg
On Thu, Mar 10, 2022 at 4:00 PM David G. Johnston
wrote:
> I dislike changing the documented behavior of CREATEROLE to the degree
> suggested here. However, there are three choices here, only one of which can
> be chosen:
>
> 1. Leave CREATEROLE alone entirely
> 2. Make it so CREATEROLE cannot
On Thu, Mar 10, 2022 at 02:22:05PM -0500, Robert Haas wrote:
> I mean, I didn't design pg_hba.conf, but I think it's part of the
> database doing a reasonable thing, not an external system doing a
> nonsensical thing.
FYI, I think pg_hba.conf gets away with having negative/reject
permissions only
On Thu, Mar 10, 2022 at 3:41 PM Stephen Frost wrote:
> > Gosh, I feel like I've spelled that out approximately 463,121 times
> > already. That estimate might be slightly off though; I've been known
> > to make mistakes from time to time
>
> If there's a specific message that details it closely
On Thu, Mar 10, 2022 at 12:58 PM Stephen Frost wrote:
> I don't think we're that far from having all of these though. To start
> with, we remove from CREATEROLE the random things that it does which go
> beyond what folks tend to expect- remove the whole 'grant any role to
> any other' stuff, rem
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Mar 10, 2022 at 2:58 PM Stephen Frost wrote:
> > It'd be useful to have a better definition of exactly what a
> > 'mini-superuser' is, but at least for the moment when it comes to roles,
> > let's look at what the spec says:
>
> G
On Thu, Mar 10, 2022 at 2:58 PM Stephen Frost wrote:
> It'd be useful to have a better definition of exactly what a
> 'mini-superuser' is, but at least for the moment when it comes to roles,
> let's look at what the spec says:
Gosh, I feel like I've spelled that out approximately 463,121 times
al
On Thu, Mar 10, 2022 at 12:45 PM Stephen Frost wrote:
>
> * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > On Thu, Mar 10, 2022 at 11:05 AM Stephen Frost
> wrote:
>
Why not just look at the admin_option field of pg_auth_members...? I
> don't get why that isn't an even more minimal fi
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> But that's not to say that we couldn't decide to do something else
> instead, and that other thing might well be better. Do you want to
> sketch out a full proposal, even just what the syntax would look like,
> and share that here? And if y
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Thu, Mar 10, 2022 at 11:05 AM Stephen Frost wrote:
> > * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > > On Thu, Mar 10, 2022 at 9:19 AM Stephen Frost wrote:
> > > > * David G. Johnston (david.g.johns...@gmail.co
On Thu, Mar 10, 2022 at 11:05 AM Stephen Frost wrote:
> Greetings,
>
> * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > On Thu, Mar 10, 2022 at 9:19 AM Stephen Frost
> wrote:
> > > * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > > > On Thu, Mar 10, 2022 at 7:46 AM Robert H
On Thu, Mar 10, 2022 at 2:05 PM Peter Eisentraut
wrote:
> On 09.03.22 14:02, Robert Haas wrote:
> > On Wed, Mar 9, 2022 at 7:55 AM Peter Eisentraut
> > wrote:
> >> Do we have subtractive permissions today?
> >
> > Not in the GRANT/REVOKE sense, I think, but you can put a user in a
> > group and t
On 09.03.22 14:02, Robert Haas wrote:
On Wed, Mar 9, 2022 at 7:55 AM Peter Eisentraut
wrote:
Do we have subtractive permissions today?
Not in the GRANT/REVOKE sense, I think, but you can put a user in a
group and then mention that group in pg_hba.conf. And that line might
be "reject" or whate
On Thu, Mar 10, 2022 at 12:26 PM Joshua Brindle
wrote:
> Ownership implies DAC, the ability to grant others rights to an
> object. It's not "kooky" to see roles as owned objects, but it isn't
> required either. For example most objects on a UNIX system are owned
> and subject to DAC but users aren
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Thu, Mar 10, 2022 at 9:19 AM Stephen Frost wrote:
> > * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > > On Thu, Mar 10, 2022 at 7:46 AM Robert Haas
> > wrote:
> > > > On Wed, Mar 9, 2022 at 4:31 PM Tom Lane wrot
On Thu, Mar 10, 2022 at 12:11 PM Robert Haas wrote:
>
> On Thu, Mar 10, 2022 at 11:19 AM Stephen Frost wrote:
> > I disagree that ownership is needed that's not what the spec calls for
> > either. What we need is more flexibility when it comes to the
> > relationships which are allowed to be cre
On Thu, Mar 10, 2022 at 9:19 AM Stephen Frost wrote:
> Greetings,
>
> * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > On Thu, Mar 10, 2022 at 7:46 AM Robert Haas
> wrote:
> > > On Wed, Mar 9, 2022 at 4:31 PM Tom Lane wrote:
> > > > I don't think we need syntax to describe it. As I
On Thu, Mar 10, 2022 at 11:19 AM Stephen Frost wrote:
> I disagree that ownership is needed that's not what the spec calls for
> either. What we need is more flexibility when it comes to the
> relationships which are allowed to be created between roles and what
> privileges come with them. To th
> On Mar 10, 2022, at 7:56 AM, David G. Johnston
> wrote:
>
>
> I want that because I want mini-superusers, where alice can administer
> the users that alice creates just as if she were a superuser,
> including having their permissions implicitly and dropping them when
> she wants them gone,
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Thu, Mar 10, 2022 at 7:46 AM Robert Haas wrote:
> > On Wed, Mar 9, 2022 at 4:31 PM Tom Lane wrote:
> > > I don't think we need syntax to describe it. As I just said in my
> > > other reply, we have a perfectly good preceden
On Thu, Mar 10, 2022 at 7:46 AM Robert Haas wrote:
> On Wed, Mar 9, 2022 at 4:31 PM Tom Lane wrote:
> > I don't think we need syntax to describe it. As I just said in my
> > other reply, we have a perfectly good precedent for this already
> > in ordinary object permissions. That is: an object
On Wed, Mar 9, 2022 at 4:31 PM Tom Lane wrote:
> I don't think we need syntax to describe it. As I just said in my
> other reply, we have a perfectly good precedent for this already
> in ordinary object permissions. That is: an object owner always,
> implicitly, has GRANT OPTION for all the obje
"David G. Johnston" writes:
> So CREATE ROLE will assign ownership of AND membership in the newly created
> role to the session_user
I would NOT have it automatically assign membership in the new role,
even though the SQL spec says so. We've not done that historically
and it doesn't seem desirab
On Wed, Mar 9, 2022 at 2:31 PM Tom Lane wrote:
> Robert Haas writes:
> > Well, the problem is that as far as I can see, the admin option is an
> > optional feature of membership. You can grant someone membership
> > without admin option, or with admin option, but you can't grant them
> > the adm
Robert Haas writes:
> Well, the problem is that as far as I can see, the admin option is an
> optional feature of membership. You can grant someone membership
> without admin option, or with admin option, but you can't grant them
> the admin option without membership, just like you can't purchase
I wrote:
> This seems like a reasonable answer to me too: the creating role has admin
> option implicitly, and can then choose to grant that to other roles.
> Obviously some work needs to be done to make that happen (and we should
> see whether the SQL spec has some different idea).
Ah, here we go
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Mar 9, 2022 at 4:01 PM Tom Lane wrote:
> > > In my opinion, the right to
> > > administer a role - regardless of whether or not it is a login role -
> > > most naturally vests in the role that created it, or something in that
> > >
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Mar 7, 2022, at 12:16 PM, Tom Lane wrote:
> > tgl> Having said that, one thing that I find fishy is that it's not clear
> > tgl> where the admin privilege for a role originates. After "CREATE ROLE
> > tgl> alice", al
On Wed, Mar 9, 2022 at 4:01 PM Tom Lane wrote:
> > In my opinion, the right to
> > administer a role - regardless of whether or not it is a login role -
> > most naturally vests in the role that created it, or something in that
> > direction at least, if not that exact thing.
>
> This seems like a
Robert Haas writes:
> On Mar 7, 2022, at 12:16 PM, Tom Lane wrote:
> tgl> Having said that, one thing that I find fishy is that it's not clear
> tgl> where the admin privilege for a role originates. After "CREATE ROLE
> tgl> alice", alice has no members, therefore none that have admin privilege,
On Mon, Mar 7, 2022 at 11:14 PM Mark Dilger
wrote:
> > On Mar 7, 2022, at 12:16 PM, Tom Lane wrote:
> > What would be
> > lost if we drop it?
>
> I looked into this a bit. Removing that bit of code, the only regression
> test changes for "check-world" are the expected ones, with nothing else
>
On Wed, Mar 9, 2022 at 7:55 AM Peter Eisentraut
wrote:
> Do we have subtractive permissions today?
Not in the GRANT/REVOKE sense, I think, but you can put a user in a
group and then mention that group in pg_hba.conf. And that line might
be "reject" or whatever.
--
Robert Haas
EDB: http://www.en
On 07.03.22 19:18, Robert Haas wrote:
That all said, permissions SHOULD BE strictly additive. If boss doesn't want
to be a member of pg_read_all_files allowing them to revoke themself from that
role seems like it should be acceptable. If there is fear in allowing someone
to revoke (not add)
> On Mar 7, 2022, at 12:16 PM, Tom Lane wrote:
>
> What would be
> lost if we drop it?
I looked into this a bit. Removing that bit of code, the only regression test
changes for "check-world" are the expected ones, with nothing else breaking.
Running installcheck+pg_upgrade to the patched v
On Mon, Mar 7, 2022 at 1:16 PM Tom Lane wrote:
> Based on Robert's archaeological dig, it now seems that the fact that
> we have any such behavior at all was just a mistake. What would be
> lost if we drop it?
>
Probably nothing that couldn't be replaced, and with a better model, but I
do have
Mark Dilger writes:
>> On Mar 7, 2022, at 12:01 PM, Robert Haas wrote:
>>
>> It's been pointed out upthread that this would have undesirable
>> security implications, because the admin option would be inherited,
>> and the implicit permission isn't.
> Right, but with a reflexive self-admin-opti
> On Mar 7, 2022, at 12:03 PM, Mark Dilger wrote:
>
> Right, but with a reflexive self-admin-option, we could document that it
> works in a non-inherited way. We'd just be saying the current hard-coded
> behavior is an option which can be revoked rather than something you're stuck
> with.
> On Mar 7, 2022, at 12:01 PM, Robert Haas wrote:
>
> It's been pointed out upthread that this would have undesirable
> security implications, because the admin option would be inherited,
> and the implicit permission isn't.
Right, but with a reflexive self-admin-option, we could document tha
On Mon, Mar 7, 2022 at 2:59 PM Mark Dilger wrote:
> This test failure is just a manifestation of the intended change, but
> assuming we make no other changes, the error message would clearly need to be
> updated, because it suggests the role should have admin_option on itself, a
> situation whi
> On Mar 7, 2022, at 10:28 AM, Tom Lane wrote:
>
> Does anything interesting break if you do just take it out?
SET SESSION AUTHORIZATION regress_priv_group2;
GRANT regress_priv_group2 TO regress_priv_user5; -- ok: a role can self-admin
-NOTICE: role "regress_priv_user5" is already a member
On Mon, Mar 7, 2022 at 2:29 PM David G. Johnston
wrote:
> You mean the one that was based upon your "ooops"...I discounted that
> immediately because members cannot revoke their own membership in a group
> unless they were given WITH ADMIN OPTION on that group.
Oh, hmm. That example might be ba
On Mon, Mar 7, 2022 at 11:18 AM Robert Haas wrote:
> In terms of how
>
things work today, see Joshua Brindle's email about the use of groups
> in pg_hba.conf. That is an excellent example of how removing oneself
> from a group could enable one to bypass security restrictions intended
> by the DBA
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I'm not quite following this bit. Where would SET ROLE come into play
> > when we're talking about old dump scripts and how the commands in those
> > scripts might be interpreted by newer versions of PG..?
>
> No, the
On Mon, Mar 7, 2022 at 1:58 PM Tom Lane wrote:
> Stephen Frost writes:
> > I'm not quite following this bit. Where would SET ROLE come into play
> > when we're talking about old dump scripts and how the commands in those
> > scripts might be interpreted by newer versions of PG..?
>
> No, the con
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Agreed, this is not something to move on quickly. We might want
> >> to think about adjusting pg_dump to use explicit GRANTED BY
> >> options in GRANT/REVOKE a release or two
Stephen Frost writes:
> I'm not quite following this bit. Where would SET ROLE come into play
> when we're talking about old dump scripts and how the commands in those
> scripts might be interpreted by newer versions of PG..?
No, the concern there is the other way around: what if you take a
scri
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Agreed, this is not something to move on quickly. We might want
>> to think about adjusting pg_dump to use explicit GRANTED BY
>> options in GRANT/REVOKE a release or two before making incompatible
>> changes.
> I'm with Robert on
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Mar 6, 2022 at 11:34 AM Tom Lane wrote:
> > I was thinking the former ... however, after a bit of experimentation
> > I see that we accept "grant foo to bar granted by baz" a VERY long
> > way back, but the "granted by" option for
On Mon, Mar 7, 2022 at 11:18 AM Robert Haas wrote:
> On Sun, Mar 6, 2022 at 11:01 PM David G. Johnston
> wrote:
> > The example, which you moved here, then attempts to demonstrate this
> "fact" but gets it wrong. Boss became a member of peon so if you want to
> demonstrate self-administration o
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > 1. What should be the exact rule for whether A can remove a grant made
> > by B? Is it has_privs_of_role()? is_member_of_role()? Something else?
>
> No strong opinion here, but I'd lean slightly to the more restrictive
>
On Mon, Mar 7, 2022 at 1:28 PM Tom Lane wrote:
> Ugh, I think you are right. It's been a long time of course, but it sure
> looks like that was copied-and-pasted without recognizing that it was
> wrong in this function because of the need to check the admin_option flag.
> And then in the later se
Robert Haas writes:
> It appears to me that the actual behavior of having is_admin_of_role()
> return true when member == role dates to
> f9fd1764615ed5d85fab703b0ffb0c323fe7dfd5 (Tom Lane, 2005). If I'm not
> reading this code wrong, prior to that commit, it seems to me that we
> only searched th
On Sun, Mar 6, 2022 at 11:01 PM David G. Johnston
wrote:
> The example, which you moved here, then attempts to demonstrate this "fact"
> but gets it wrong. Boss became a member of peon so if you want to
> demonstrate self-administration of a role's membership in a different group
> you have to
On Mon, Mar 7, 2022 at 11:04 AM Tom Lane wrote:
> > Is there some use case for the behavior described in that last
> > sentence?
>
> Good question. You might try figuring out when that text was added
> and then see if there's relevant discussion in the archives.
Apparently the permission used to
On Mon, Mar 7, 2022 at 9:04 AM Tom Lane wrote:
> Just looking at it now, without having done any historical research,
>
I wonder why it is that we don't attach significance to WITH ADMIN
> OPTION being granted to the role itself. It seems like the second
> part of that sentence is effectively sa
Robert Haas writes:
> Hmm. I think the real issue is what David Johnson calls the session
> user exception. I hadn't quite understood how that played into this.
> According to the documentation: "If WITH ADMIN OPTION is specified,
> the member can in turn grant membership in the role to others, an
On Mon, Mar 7, 2022 at 8:37 AM Robert Haas wrote:
> A role is not considered to hold WITH
> ADMIN OPTION on itself, but it may grant or revoke membership in
> itself from a database session where the session user matches the
> role."
>
> Is there some use case for the behavior described in that l
On Sun, Mar 6, 2022 at 2:09 PM David G. Johnston
wrote:
> So, do we really want to treat every single login role as a potential group
> by keeping the session_user exception?
I think that we DO want to continue to treat login roles as
potentially grantable privileges. That feels fundamentally us
On Sun, Mar 6, 2022 at 11:53 AM Tom Lane wrote:
> Really?
>
> regression=# grant admin to joe;
> GRANT ROLE
> regression=# grant admin to sally;
> GRANT ROLE
> regression=# \c - joe
> You are now connected to database "regression" as user "joe".
> regression=> revoke admin from sally;
> ERROR: mu
On Sun, Mar 6, 2022 at 11:34 AM Tom Lane wrote:
> I was thinking the former ... however, after a bit of experimentation
> I see that we accept "grant foo to bar granted by baz" a VERY long
> way back, but the "granted by" option for object privileges is
> (a) pretty new and (b) apparently restrict
On Sun, Mar 6, 2022 at 8:19 AM Robert Haas wrote:
> The choice of names in my example wasn't accidental. If the granted
> role is a login role, then the superuser's intention was to vest the
> privileges of that role in some other role, and it is surely not right
> for that role to be able to dec
On Sun, Mar 6, 2022 at 9:53 AM Tom Lane wrote:
> Robert Haas writes:
> > ... Suppose the superuser grants "admin" to both "joe" and "sally".
> > Now "joe" can SET ROLE to "admin" and revoke it from "sally", and the
> > superuser has no tool to prevent this.
>
> Really?
>
> regression=# grant adm
Robert Haas writes:
> ... Suppose the superuser grants "admin" to both "joe" and "sally".
> Now "joe" can SET ROLE to "admin" and revoke it from "sally", and the
> superuser has no tool to prevent this.
Really?
regression=# grant admin to joe;
GRANT ROLE
regression=# grant admin to sally;
GRANT
On Sun, Mar 6, 2022 at 10:19 AM Robert Haas wrote:
>
> On Fri, Mar 4, 2022 at 5:20 PM David G. Johnston
> wrote:
> > I think I disagree. Or, at least, the superuser has full control of
> > dictating how role membership is modified and that seems sufficient.
>
> The point is that the superuser D
Robert Haas writes:
> On Fri, Mar 4, 2022 at 4:34 PM Tom Lane wrote:
>> Agreed, this is not something to move on quickly. We might want
>> to think about adjusting pg_dump to use explicit GRANTED BY
>> options in GRANT/REVOKE a release or two before making incompatible
>> changes.
> Uggh. I rea
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.
Hmm, so maybe that's the place to start. We are tracking it in the
sense that we record an OID in the catalog, but nothing that happe
On Fri, Mar 4, 2022 at 5:20 PM David G. Johnston
wrote:
> I think I disagree. Or, at least, the superuser has full control of
> dictating how role membership is modified and that seems sufficient.
The point is that the superuser DOES NOT have full control. The
superuser cannot prevent relativel
On Fri, Mar 4, 2022 at 1:50 PM Robert Haas wrote:
> On Mon, Feb 28, 2022 at 2:09 PM Stephen Frost wrote:
> > The ability of a role to revoke itself from some other role is just
> > something we need to accept as being a change that needs to be made, and
> > I do believe that such a change is sup
Robert Haas writes:
> 1. What should be the exact rule for whether A can remove a grant made
> by B? Is it has_privs_of_role()? is_member_of_role()? Something else?
No strong opinion here, but I'd lean slightly to the more restrictive
option.
> 2. What happens if the same GRANT is enacted by mul
On Mon, Feb 28, 2022 at 2:09 PM Stephen Frost wrote:
> The ability of a role to revoke itself from some other role is just
> something we need to accept as being a change that needs to be made, and
> I do believe that such a change is supported by the standard, in that a
> REVOKE will only work if
100 matches
Mail list logo
