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 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
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
[ 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
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
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
> > -
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
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
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
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
> >
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
> 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
> 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
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
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
> 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
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
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
> 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
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
> 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,
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
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
>
> 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
>
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
> 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
>
> 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,
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
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
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
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
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
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
> 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:
> 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
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
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
> 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
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
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
> 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
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
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
> 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
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.)
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 that way, but the perceived
value of
61 matches
Mail list logo
