On Fri, Apr 1, 2022 at 10:46 AM Greg Stark wrote:
> The cfbot is testing the last patch posted to this thread which is the
> remove-self-own patch which was already committed. I gather that
> there's still (at least one) patch under discussion.
>
> Could I suggest reposting the last version of the
The cfbot is testing the last patch posted to this thread which is the
remove-self-own patch which was already committed. I gather that
there's still (at least one) patch under discussion.
Could I suggest reposting the last version of the main patch, perhaps
rebasing it. That way the cfbot would a
On Mon, Feb 28, 2022 at 2:09 PM Stephen Frost wrote:
> I'm generally in support of changing CREATEROLE to only allow roles that
> the role with CREATEROLE is an admin of to be allowed as part of the
> command (throwing an error in other cases). That doesn't solve other
> use-cases which would cer
[ Been away, catching up on email. ]
On Tue, Feb 22, 2022 at 10:54 AM Joshua Brindle
wrote:
> Yes, absolutely. It is my understanding that generally a community
> consensus is attempted, I was throwing my (and Crunchy's) use case out
> there as a possible goal, and I have spent time reviewing and
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> 1. Don't allow a CREATEROLE user to give out membership in groups
> which that user does not possess. Leaving aside the details of any
> previously-proposed patches and just speaking theoretically, how can
> this be implemented? I can think
On Thu, Feb 17, 2022 at 12:40 PM Robert Haas wrote:
>
> On Mon, Jan 31, 2022 at 1:57 PM Joshua Brindle
> wrote:
> > This is precisely the use case I am trying to accomplish with this
> > patchset, roughly:
> >
> > - An automated bot that creates users and adds them to the employees role
> > - Bot
On Mon, Jan 31, 2022 at 1:57 PM Joshua Brindle
wrote:
> This is precisely the use case I am trying to accomplish with this
> patchset, roughly:
>
> - An automated bot that creates users and adds them to the employees role
> - Bot cannot access any employee (or other roles) table data
> - Bot canno
I'm chiming in a little late here, but as someone who worked on a
system to basically work around the lack of unprivileged CREATE ROLE
for a cloud provider (I worked on the Heroku Data team for several
years), I thought it might be useful to offer my perspective. This is,
of course, not the only us
On Wed, Feb 2, 2022 at 3:23 PM Mark Dilger wrote:
> It's perfectly reasonable (in my mind) that Robert, acting as superuser, may
> want to create a creator who acts like a superuser over the sandbox, while at
> the same time Stephen, acting as superuser, may want to create a creator who
> acts
> On Feb 2, 2022, at 11:52 AM, Stephen Frost wrote:
>
> The question that we need to solve is how to give
> users the ability to choose what roles have which of the privileges that
> we've outlined above and agreed should be separable.
Ok, there are really two different things going on here,
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Jan 31, 2022, at 10:50 AM, Stephen Frost wrote:
> > Supporting that through ADMIN is one option, another would be a
> > 'DROPROLE' attribute, though we'd want a way to curtail that from being
> > able to be used for just any ro
On Tue, Feb 1, 2022 at 6:38 PM Andrew Dunstan wrote:
> > In existing postgresql releases, having CREATEROLE means you can give away
> > most attributes, including ones you yourself don't have (createdb, login).
> > So we already have the concept of NOFOO WITH ADMIN OPTION, we just don't
> > ca
On 2/1/22 17:27, Mark Dilger wrote:
>
>> On Feb 1, 2022, at 1:10 PM, Andrew Dunstan wrote:
>>
>> The whole 'NOFOO WITH ADMIN OPTION'
>> thing seems to me a bit like a POLA violation. Nevertheless I can
>> probably live with it as long as it's *really* well documented. Even so
>> I suspect it wou
> On Feb 1, 2022, at 1:10 PM, Andrew Dunstan wrote:
>
> The whole 'NOFOO WITH ADMIN OPTION'
> thing seems to me a bit like a POLA violation. Nevertheless I can
> probably live with it as long as it's *really* well documented. Even so
> I suspect it would be too complex for many, and they will
On 1/31/22 12:18, Mark Dilger wrote:
>
>> On Jan 31, 2022, at 12:43 AM, Michael Banck
>> wrote:
>> Ok, sure. I think this topic is hugely important and as I read the
>> patch anyway, I added some comments, but yeah, we need to figure out
>> the fundamentals first.
> Right.
>
> Perhaps some back
> On Jan 31, 2022, at 10:50 AM, Stephen Frost wrote:
>
> Supporting that through ADMIN is one option, another would be a
> 'DROPROLE' attribute, though we'd want a way to curtail that from being
> able to be used for just any role and that does lead down a path similar
> to ownership or just g
Hi,
Am Montag, dem 31.01.2022 um 09:18 -0800 schrieb Mark Dilger:
> On Jan 31, 2022, at 12:43 AM, Michael Banck <
> michael.ba...@credativ.de> wrote:
> Ok, sure. I think this topic is hugely important and as I read the
> patch anyway, I added some comments, but yeah, we need to figure out
> the
On Mon, Jan 31, 2022 at 1:50 PM Stephen Frost wrote:
>
> Greetings,
>
> * Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > > On Jan 31, 2022, at 8:53 AM, Stephen Frost wrote:
> > > Yeah, we do need to have a way to determine who is allowed to drop
> > > roles and role ownership seems like it
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Jan 31, 2022, at 8:53 AM, Stephen Frost wrote:
> > Yeah, we do need to have a way to determine who is allowed to drop
> > roles and role ownership seems like it's one possible approach to that.
>
> Which other ways are on the
> On Jan 31, 2022, at 8:53 AM, Stephen Frost wrote:
>
> Yeah, we do need to have a way to determine who is allowed to drop
> roles and role ownership seems like it's one possible approach to that.
Which other ways are on the table? Having ADMIN on a role doesn't allow you to
do that, but ma
> On Jan 31, 2022, at 12:43 AM, Michael Banck wrote:
> Ok, sure. I think this topic is hugely important and as I read the
> patch anyway, I added some comments, but yeah, we need to figure out
> the fundamentals first.
Right.
Perhaps some background on this patch series will help. The patch
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Jan 25, 2022, at 12:44 PM, Stephen Frost wrote:
> > I agree that CREATEROLE is overpowered and that the goal of this should
> > be to provide a way for roles to be created and dropped that doesn't
> > give the user who has that
Hi,
Am Sonntag, dem 30.01.2022 um 17:11 -0800 schrieb Mark Dilger:
> > On Jan 30, 2022, at 2:38 PM, Michael Banck <
> > michael.ba...@credativ.de> wrote:
> > > The attached WIP patch attempts to solve most of the CREATEROLE
>
> I'm mostly looking for whether the general approach in this Work I
> On Jan 30, 2022, at 2:38 PM, Michael Banck wrote:
>
> Hi,
Your review is greatly appreciated!
>> The attached WIP patch attempts to solve most of the CREATEROLE
I'm mostly looking for whether the general approach in this Work In Progress
patch is acceptable, so I was a bit sloppy with wh
Hi,
On Sat, Jan 29, 2022 at 09:58:38PM -0800, Mark Dilger wrote:
> > On Jan 25, 2022, at 12:44 PM, Stephen Frost wrote:
> > I agree that CREATEROLE is overpowered and that the goal of this should
> > be to provide a way for roles to be created and dropped that doesn't
> > give the user who has th
> On Jan 25, 2022, at 12:44 PM, Stephen Frost wrote:
>
> I agree that CREATEROLE is overpowered and that the goal of this should
> be to provide a way for roles to be created and dropped that doesn't
> give the user who has that power everything that CREATEROLE currently
> does.
I'm attaching
> On Jan 25, 2022, at 12:44 PM, Stephen Frost wrote:
>
> As I mentioned in the patch review, having a particular bit set doesn't
> necessarily mean you should be able to pass it on- the existing object
> GRANT system distinguishes those two and it seems like we should too.
> In other words, I'
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Jan 24, 2022, at 2:21 PM, Stephen Frost wrote:
> > Being able to create and drop users is, in fact, effectively a
> > superuser-only task today. We could throw out the entire idea of role
> > ownership, in fact, as being ent
On Mon, Jan 24, 2022 at 5:21 PM Stephen Frost wrote:
> This is an argument to drop the role ownership concept, as I view it.
> Privileges are driven by membership today and inventing some new independent
> way to do that is increasing confusion, not improving things. I disagree
> that adding
> On Jan 24, 2022, at 2:21 PM, Stephen Frost wrote:
>
> To push back on the original “tenant” argument, consider that one of the
> bigger issues in cloud computing today is exactly the problem that the cloud
> managers can potentially gain access to the sensitive data of their tenants
> and
> On Jan 24, 2022, at 10:55 PM, Fujii Masao wrote:
>
> +1
>
> One of "mischiefs" I'm thinking problematic is that users with CREATEROLE can
> give any predefined role that they don't have, to other users including
> themselves. For example, users with CREATEROLE can give
> pg_execute_serve
On 2022/01/25 8:18, Mark Dilger wrote:
On Jan 24, 2022, at 2:21 PM, Stephen Frost wrote:
Superuser is a problem specifically because it gives people access to do
absolutely anything, both for security and safety concerns. Disallowing a way
to curtail that same risk when it comes to role
> On Jan 24, 2022, at 2:21 PM, Stephen Frost wrote:
>
> Superuser is a problem specifically because it gives people access to do
> absolutely anything, both for security and safety concerns. Disallowing a way
> to curtail that same risk when it comes to role ownership invites exactly
> thos
> On Jan 24, 2022, at 2:21 PM, Stephen Frost wrote:
>
> Being able to create and drop users is, in fact, effectively a superuser-only
> task today. We could throw out the entire idea of role ownership, in fact,
> as being entirely unnecessary when talking about that specific task.
Wow, tha
Greetings,
On Mon, Jan 24, 2022 at 16:42 Robert Haas wrote:
> On Mon, Jan 24, 2022 at 4:23 PM Stephen Frost wrote:
> > The idea behind this patch is to enable creation and dropping of roles,
> which isn’t possible now without being effectively a superuser.
> >
> > Forcing owners to also implici
On Mon, Jan 24, 2022 at 4:23 PM Stephen Frost wrote:
> The idea behind this patch is to enable creation and dropping of roles, which
> isn’t possible now without being effectively a superuser.
>
> Forcing owners to also implicitly have all rights of the roles they create is
> orthogonal to that
Greetings,
On Mon, Jan 24, 2022 at 15:33 Robert Haas wrote:
> On Sat, Jan 22, 2022 at 4:20 PM Stephen Frost wrote:
> > Whoah, really? No, I don't agree with this, it's throwing away the
> > entire concept around inheritance of role rights and how you can have
> > roles which you can get the pr
On 1/24/22 15:33, Robert Haas wrote:
> On Sat, Jan 22, 2022 at 4:20 PM Stephen Frost wrote:
>> Whoah, really? No, I don't agree with this, it's throwing away the
>> entire concept around inheritance of role rights and how you can have
>> roles which you can get the privileges of by doing a SET
On Sat, Jan 22, 2022 at 4:20 PM Stephen Frost wrote:
> Whoah, really? No, I don't agree with this, it's throwing away the
> entire concept around inheritance of role rights and how you can have
> roles which you can get the privileges of by doing a SET ROLE to them
> but you don't automatically h
On 1/22/22 16:20, Stephen Frost wrote:
>> Subject: [PATCH v4 1/5] Add tests of the CREATEROLE attribute.
> No particular issue with this one.
>
>
I'm going to commit this piece forthwith so we get it out of the way.
That will presumably make the cfbot unhappy until Mark submits a new
patch set.
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Jan 4, 2022, at 12:47 PM, Joshua Brindle
> > wrote:
> >
> >> I was able to reproduce that using REASSIGN OWNED BY to cause a user to
> >> own itself. Is that how you did it, or is there yet another way to get
> >> into tha
On 1/5/22 19:05, Mark Dilger wrote:
>
>> On Jan 4, 2022, at 12:47 PM, Joshua Brindle
>> wrote:
>>
>>> I was able to reproduce that using REASSIGN OWNED BY to cause a user to own
>>> itself. Is that how you did it, or is there yet another way to get into
>>> that state?
>> I did:
>> ALTER ROL
On Wed, Jan 5, 2022 at 7:05 PM Mark Dilger wrote:
> > On Jan 4, 2022, at 12:47 PM, Joshua Brindle
> > wrote:
> >
> >> I was able to reproduce that using REASSIGN OWNED BY to cause a user to
> >> own itself. Is that how you did it, or is there yet another way to get
> >> into that state?
> >
On Tue, Jan 4, 2022 at 3:39 PM Mark Dilger wrote:
>
>
>
> > On Jan 4, 2022, at 9:07 AM, Mark Dilger
> > wrote:
> >
> > No, that looks like a bug.
>
> I was able to reproduce that using REASSIGN OWNED BY to cause a user to own
> itself. Is that how you did it, or is there yet another way to get
> On Jan 4, 2022, at 9:07 AM, Mark Dilger wrote:
>
> No, that looks like a bug.
I was able to reproduce that using REASSIGN OWNED BY to cause a user to own
itself. Is that how you did it, or is there yet another way to get into that
state?
—
Mark Dilger
EnterpriseDB: http://www.enterprise
> On Jan 4, 2022, at 6:35 AM, Joshua Brindle
> wrote:
>
> I just ran across this and I don't know if it is intended behavior or
> not
> postgres=> \password
> Enter new password for user "brindle":
> Enter it again:
> ERROR: role "brindle" with OID 16384 owns itself
No, that looks like a
On Mon, Jan 3, 2022 at 5:08 PM Andrew Dunstan wrote:
>
>
> On 12/23/21 16:06, Joshua Brindle wrote:
> > On Tue, Dec 21, 2021 at 8:26 PM Mark Dilger
> > wrote:
> >>
> >>
> >>> On Dec 21, 2021, at 5:11 PM, Shinya Kato
> >>> wrote:
> >>>
> >>> I fixed the patches because they cannot be applied to
On 12/23/21 16:06, Joshua Brindle wrote:
> On Tue, Dec 21, 2021 at 8:26 PM Mark Dilger
> wrote:
>>
>>
>>> On Dec 21, 2021, at 5:11 PM, Shinya Kato
>>> wrote:
>>>
>>> I fixed the patches because they cannot be applied to HEAD.
>> Thank you.
> I reviewed and tested these and they LGTM. FYI the r
On Tue, Dec 21, 2021 at 8:26 PM Mark Dilger
wrote:
>
>
>
> > On Dec 21, 2021, at 5:11 PM, Shinya Kato
> > wrote:
> >
> > I fixed the patches because they cannot be applied to HEAD.
>
> Thank you.
I reviewed and tested these and they LGTM. FYI the rebased v3 patches
upthread are raw diffs so git
> On Dec 21, 2021, at 5:11 PM, Shinya Kato
> wrote:
>
> I fixed the patches because they cannot be applied to HEAD.
Thank you.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 2021-10-28 07:21, Mark Dilger wrote:
On Oct 25, 2021, at 10:09 PM, Shinya Kato
wrote:
Hi! Thank you for the patch.
I too think that CREATEROLE escalation attack is problem.
I have three comments.
1. Is there a function to check the owner of a role, it would be nice
to be able to check wi
On 2021-10-29 01:14, Tom Lane wrote:
Mark Dilger writes:
The only intentional backward compatibility break in this patch set is
the the behavior of CREATEROLE. The general hope is that such a
compatibility break will help far more than it hurts, as CREATEROLE
does not appear to be a well ado
Mark Dilger writes:
> The only intentional backward compatibility break in this patch set is the
> the behavior of CREATEROLE. The general hope is that such a compatibility
> break will help far more than it hurts, as CREATEROLE does not appear to be a
> well adopted feature. I would expect t
> On Oct 27, 2021, at 7:32 PM, Shinya Kato
> wrote:
>
> I was able to add the membership of a role with a different owner.
> In brief, "a" was able to change the membership of owner "shinya".
> Is this the correct behavior?
I believe it is required for backwards compatibility. In a green fi
On 2021-10-28 07:21, Mark Dilger wrote:
On Oct 25, 2021, at 10:09 PM, Shinya Kato
wrote:
Hi! Thank you for the patch.
I too think that CREATEROLE escalation attack is problem.
I have three comments.
1. Is there a function to check the owner of a role, it would be nice
to be able to check wi
On 10/21/21 19:21, Mark Dilger wrote:
>> Also, are we just going to strip
>> the current CREATEROLE roles of much of their powers? Maybe it's
>> worth keeping a legacy CREATEROLE role attribute for upgraded clusters
>> that could eventually be removed down the road.
> The patch as written drast
> On Oct 25, 2021, at 10:09 PM, Shinya Kato
> wrote:
>
> On 2021-10-21 03:40, Mark Dilger wrote:
>> These patches have been split off the now deprecated monolithic
>> "Delegating superuser tasks to new security roles" thread at [1].
>> The purpose of these patches is to fix the CREATEROLE esc
On 2021-10-21 03:40, Mark Dilger wrote:
These patches have been split off the now deprecated monolithic
"Delegating superuser tasks to new security roles" thread at [1].
The purpose of these patches is to fix the CREATEROLE escalation
attack vector misfeature. (Not everyone will see CREATEROLE
> On Oct 21, 2021, at 4:04 PM, Bossart, Nathan wrote:
>
> Regarding the "attack vector misfeature" comment, I remember being
> surprised when I first learned how much roles with CREATEROLE can do.
> When I describe CREATEROLE to others, I am sure to emphasize the note
> in the docs about such
On 10/20/21, 11:46 AM, "Mark Dilger" wrote:
> The purpose of these patches is to fix the CREATEROLE escalation
> attack vector misfeature. (Not everyone will see CREATEROLE that
> way, but the perceived value of the patch set likely depends on how
> much you see CREATEROLE in that light.)
Regard
60 matches
Mail list logo
