From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Orphaned users in PG16 and above can only be managed by Superusers |
Date: | 2025-01-21 16:51:51 |
Message-ID: | CA+Tgmob7pgFw2o10D=oOH=h-8JyM58tyE0bpA7kM-EryB=Yz1w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 9, 2025 at 12:31 AM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> 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 typically have the ability to
> manage/administer userC. However, if userB is dropped, userA (the
> grandparent of userC) loses the ability to administer userC as well.
> This leads to a situation where only superusers can manage userC.
>
> Shouldn't userA retain the permission to manage userC even if userB is
> removed? Otherwise, only superusers would have the authority to
> administer userC (the orphaned user in this case), which may not be
> feasible for cloud environments where superuser access is restricted.
This doesn't seem great, but it's not clear to me what we should do
about it. It doesn't really seem reasonable to me to change the role
grants that point to userB to make them point to userA instead. After
all, there could be multiple sets of role grants pointing to userB and
there could be multiple sets of role grants from userB pointing
elsewhere and they could all have different options (admin, set,
inherit). It doesn't feel right to have DROP ROLE make a bunch of
arbitrary decisions about what to do about that. We could make DROP
ROLE userB fail, perhaps, and tell the user they need to sort it out
first, but I'm not entirely sure that we have the right tools to allow
the user to do that in a convenient way. If userC were instead tableC,
DROP OWNED or REASSIGN OWNED could be used.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-01-21 17:18:11 | Re: How to deinitialize a connection for background worker |
Previous Message | Jacob Champion | 2025-01-21 16:46:43 | Re: [PoC] Federated Authn/z with OAUTHBEARER |