On Mon, Mar 24, 2025 at 2:18 AM Ashutosh Sharma wrote:
> Thank you, Robert and Tom, for sharing your valuable insights, and
> apologies for the slight delay in my response. From the discussion,
> what I understand is that we aim to extend the current DROP ROLE
> syntax to include the CASCADE/RESTR
Thank you, Robert and Tom, for sharing your valuable insights, and
apologies for the slight delay in my response. From the discussion,
what I understand is that we aim to extend the current DROP ROLE
syntax to include the CASCADE/RESTRICT option, which has been
introduced in the latest SQL standard
On Thu, Mar 13, 2025 at 1:44 AM Ashutosh Sharma wrote:
> On Wed, Mar 12, 2025 at 9:06 PM Nathan Bossart
> wrote:
> > I think this approach has other problems. For example, even if a role has
> > admin directly on the dropped role, we'll block DROP ROLE if it also has
> > admin indirectly:
> >
>
Robert Haas writes:
> On Wed, Mar 19, 2025 at 2:32 PM Tom Lane wrote:
>> Perhaps if we implemented RESTRICT/CASCADE here, that would
>> at least make it harder to fall into this trap?
> I have always assumed that the reason DROP ROLE blah CASCADE is not
> implemented is (1) it would have to casc
On Wed, Mar 19, 2025 at 2:32 PM Tom Lane wrote:
> I didn't assert that that's a general problem. I meant that this
> particular patch makes life worse, by causing DROP ROLE to fail
> unexpectedly.
I think that's only true of this particular version of the patch. I
believe it's likely resolvable
Robert Haas writes:
> On Wed, Mar 19, 2025 at 1:55 PM Tom Lane wrote:
>> I'm especially against making life more difficult for everyone who
>> uses Postgres in order to remove a problem that's only a problem for
>> people who don't have a superuser account available.
> You kind of lost me at thi
On Wed, Mar 19, 2025 at 1:55 PM Tom Lane wrote:
> That being the case, I'm against imposing restrictions on DROP ROLE
> because of the properties of particular role grants. If you get
> into a situation where you need a superuser's help to undo something,
> well hopefully you learned better and w
Robert Haas writes:
> if I say I want to DROP ROLE b, I'm going to have to first REVOKE c
> FROM b -- there is no real other alternative. So why not make that
> happen automatically? When I say I want to DROP something, I'm
> serious: I really want it gone.
For privileges on ordinary objects, we
On Wed, Mar 19, 2025 at 10:28 AM Robert Haas wrote:
> I in general dislike throwing up barriers that prevent objects from
> being dropped. As a user, I find such rules frustrating, especially if
> I'm still allowed to accomplish the same drop indirectly by some
> series of commands (e.g. REVOKE f
Hi,
On Thu, Mar 13, 2025 at 11:14 AM Ashutosh Sharma wrote:
>
> Hi,
>
> On Wed, Mar 12, 2025 at 9:06 PM Nathan Bossart
> wrote:
> >
> > There are also other ways besides DROP ROLE that roles can end up without
> > any admins:
> >
> > postgres=# create role a createrole;
> > CREA
Hi,
On Wed, Mar 12, 2025 at 9:06 PM Nathan Bossart wrote:
>
> I think this approach has other problems. For example, even if a role has
> admin directly on the dropped role, we'll block DROP ROLE if it also has
> admin indirectly:
>
This is exactly what we're aiming for. We don't want the ADMIN
On Wed, Mar 12, 2025 at 12:10:30PM +0530, Ashutosh Sharma wrote:
> I think moving the check to the second pass won´t work in this case.
> The reason is that we rely on entries in the pg_auth_members table. By
> the time the check occurs in the second pass, the first pass will have
> already removed
Hi Nathan,
On Mon, Mar 10, 2025 at 8:31 PM Nathan Bossart wrote:
>
> On Mon, Mar 10, 2025 at 11:15:04AM +0530, Ashutosh Sharma wrote:
> > On Fri, Mar 7, 2025 at 10:55 PM Nathan Bossart
> > wrote:
> >> I noticed that much of this code is lifted from DropRole(), and the new
> >> check_drop_role_d
Hi Nathan,
Thanks for the review comment.
On Mon, Mar 10, 2025 at 8:31 PM Nathan Bossart wrote:
>
> On Mon, Mar 10, 2025 at 11:15:04AM +0530, Ashutosh Sharma wrote:
> > On Fri, Mar 7, 2025 at 10:55 PM Nathan Bossart
> > wrote:
> >> I noticed that much of this code is lifted from DropRole(), an
On Mon, Mar 10, 2025 at 11:15:04AM +0530, Ashutosh Sharma wrote:
> On Fri, Mar 7, 2025 at 10:55 PM Nathan Bossart
> wrote:
>> I noticed that much of this code is lifted from DropRole(), and the new
>> check_drop_role_dependency() function is only used by DropRole() right
>> before it does the exa
Hi,
On Fri, Mar 7, 2025 at 10:55 PM Nathan Bossart wrote:
>
> I noticed that much of this code is lifted from DropRole(), and the new
> check_drop_role_dependency() function is only used by DropRole() right
> before it does the exact same scans. Couldn't we put the new dependency
> detection in
On Thu, Mar 06, 2025 at 04:10:10PM +0530, Ashutosh Sharma wrote:
> Attached is the v2 patch with the following updates:
>
> 1) Added detailed comments atop check_drop_role_dependency() to
> clarify role dependencies, addressing Nathan's comment.
Thanks!
> 2) Fixed a race condition where the depe
Hi,
Attached is the v2 patch with the following updates:
1) Added detailed comments atop check_drop_role_dependency() to
clarify role dependencies, addressing Nathan's comment.
2) Fixed a race condition where the dependency check could pass, but a
new dependency might be added before the role dr
Hi Robert,
Thanks for the review comments.
On Thu, Mar 6, 2025 at 2:10 AM Robert Haas wrote:
>
> On Wed, Mar 5, 2025 at 3:13 PM Nathan Bossart
> wrote:
> > * The patch alleges to only block DROP ROLE commands when there exists
> > _both_ admins of the target role and roles for which the targ
Thanks, Nathan, for reviewing the patch. Below are my comments inline:
On Thu, Mar 6, 2025 at 1:43 AM Nathan Bossart wrote:
>
>
> * The patch alleges to only block DROP ROLE commands when there exists
> _both_ admins of the target role and roles for which the target role is
> an admin. Howev
On Wed, Mar 5, 2025 at 3:13 PM Nathan Bossart wrote:
> * The patch alleges to only block DROP ROLE commands when there exists
> _both_ admins of the target role and roles for which the target role is
> an admin. However, it's not clear to me why both need to be true. I
> might be able to g
On Tue, Feb 18, 2025 at 02:54:46PM +0530, Ashutosh Sharma wrote:
> Attached is a patch that checks for role dependencies when the DROP
> ROLE command is executed. If dependencies are found, the command is
> prevented from succeeding. Please review the attached patch and share
> your feedback. thank
Added a commitfest entry for this here:
https://commitfest.postgresql.org/patch/5608/
--
With Regards,
Ashutosh Sharma.
On Tue, Feb 18, 2025 at 2:54 PM Ashutosh Sharma wrote:
>
> Hi Robert,
>
> On Tue, Feb 11, 2025 at 9:48 PM Ashutosh Sharma wrote:
> >
> > Hi Robert,
> >
> > On Tue, Feb 4, 202
Hi Robert,
On Tue, Feb 11, 2025 at 9:48 PM Ashutosh Sharma wrote:
>
> Hi Robert,
>
> On Tue, Feb 4, 2025 at 10:54 PM Robert Haas wrote:
> >
> > On Thu, Jan 30, 2025 at 8:45 AM Ashutosh Sharma
> > wrote:
> > > Imagine a superuser creates role u1. Since the superuser is creating
> > > u1, it won
Hi Robert,
On Tue, Feb 4, 2025 at 10:54 PM Robert Haas wrote:
>
> On Thu, Jan 30, 2025 at 8:45 AM Ashutosh Sharma wrote:
> > Imagine a superuser creates role u1. Since the superuser is creating
> > u1, it won't have membership in any role. Now, suppose u1 creates a
> > new role, u2. In this case
On Thu, Jan 30, 2025 at 8:45 AM Ashutosh Sharma wrote:
> Imagine a superuser creates role u1. Since the superuser is creating
> u1, it won't have membership in any role. Now, suppose u1 creates a
> new role, u2. In this case, u1 automatically becomes a member of u2
> with the admin option. However
Hi All,
On Fri, Jan 24, 2025 at 9:34 PM Ashutosh Sharma wrote:
>
> On Fri, Jan 24, 2025 at 8:23 PM Andrew Dunstan wrote:
> >
> >
> > On 2025-01-23 Th 4:06 PM, Robert Haas wrote:
> > > On Thu, Jan 23, 2025 at 3:51 PM Andres Freund wrote:
> > >> I wonder if it's a mistake that a role membership t
On Fri, Jan 24, 2025 at 8:23 PM Andrew Dunstan wrote:
>
>
> On 2025-01-23 Th 4:06 PM, Robert Haas wrote:
> > On Thu, Jan 23, 2025 at 3:51 PM Andres Freund wrote:
> >> I wonder if it's a mistake that a role membership that has WITH ADMIN on
> >> another role is silently removed if the member role
On Thu, Jan 23, 2025 at 03:10:16PM -0500, Tom Lane wrote:
> That line of reasoning leads to the same conclusion, that another
> built-in role might be a suitable solution --- unless said role is
> so powerful that the service providers might want to block access
> to it too. Probably limiting it t
On Fri, Jan 24, 2025 at 09:53:09AM -0500, Andrew Dunstan wrote:
> On 2025-01-23 Th 4:06 PM, Robert Haas wrote:
>> On Thu, Jan 23, 2025 at 3:51 PM Andres Freund wrote:
>> > I wonder if it's a mistake that a role membership that has WITH ADMIN on
>> > another role is silently removed if the member r
On 2025-01-23 Th 4:06 PM, Robert Haas wrote:
On Thu, Jan 23, 2025 at 3:51 PM Andres Freund wrote:
I wonder if it's a mistake that a role membership that has WITH ADMIN on
another role is silently removed if the member role is removed. We e.g. do
*not* do that for pg_auth_members.grantor:
ERR
On Thu, Jan 23, 2025 at 3:51 PM Andres Freund wrote:
> I wonder if it's a mistake that a role membership that has WITH ADMIN on
> another role is silently removed if the member role is removed. We e.g. do
> *not* do that for pg_auth_members.grantor:
>
> ERROR: 2BP01: role "r1" cannot be dropped b
On Thu, Jan 23, 2025 at 4:02 PM Robert Haas wrote:
> On Wed, Jan 22, 2025 at 6:08 AM Ashutosh Sharma wrote:
> > Thanks for sharing your thoughts and inputs. I'm also not quite clear
> > about the fix. Some of the solutions/changes you've mentioned above
> > seem quite complex and may not be reaso
On Wed, Jan 22, 2025 at 6:08 AM Ashutosh Sharma wrote:
> Thanks for sharing your thoughts and inputs. I'm also not quite clear
> about the fix. Some of the solutions/changes you've mentioned above
> seem quite complex and may not be reasonable, as you pointed out. How
> about introducing a new pre
Hi,
On 2025-01-23 20:55:25 +0100, Tomas Vondra wrote:
> If this stopped working in PG16, then how/why did it work in PG15? Is
> that intentional change?
Yes, it was intentional:
Restrict the privileges of CREATEROLE and its ability to modify other
roles (Robert Haas)
Previously ro
Tomas Vondra writes:
> So it seems to me having a predefined role that allows managing all
> roles (including orphaned ones) might be the good alternative. I
> initially wrote "cleaner", but it feels a bit wrong to allow orphaned
> roles and then have to "fix" this by having this predefined role.
On 1/22/25 12:07, Ashutosh Sharma wrote:
> Hi Robert,
>
> On Tue, Jan 21, 2025 at 10:22 PM Robert Haas wrote:
>>
>> On Thu, Jan 9, 2025 at 12:31 AM Ashutosh Sharma
>> wrote:
>>> Starting from PG16, it seems that orphaned users can only be managed
>>> by superusers. For example, if userA creates
Hi Robert,
On Tue, Jan 21, 2025 at 10:22 PM Robert Haas wrote:
>
> On Thu, Jan 9, 2025 at 12:31 AM Ashutosh Sharma wrote:
> > Starting from PG16, it seems that orphaned users can only be managed
> > by superusers. For example, if userA creates userB, and userB creates
> > userC, then both userB
On Thu, Jan 9, 2025 at 12:31 AM Ashutosh Sharma wrote:
> Starting from PG16, it seems that orphaned users can only be managed
> by superusers. For example, if userA creates userB, and userB creates
> userC, then both userB (the parent of userC) and userA (the
> grandparent of userC) would typicall
Hi All,
On Thu, Jan 9, 2025 at 11:01 AM Ashutosh Sharma
wrote:
>
> Hi All,
>
> Starting from PG16, it seems that orphaned users can only be managed
> by superusers. For example, if userA creates userB, and userB creates
> userC, then both userB (the parent of userC) and userA (the
> grandparent o
Hi All,
Starting from PG16, it seems that orphaned users can only be managed
by superusers. For example, if userA creates userB, and userB creates
userC, then both userB (the parent of userC) and userA (the
grandparent of userC) would typically have the ability to
manage/administer userC. However,
41 matches
Mail list logo
