Re: CREATEROLE and role ownership hierarchies - Mailing list pgsql-hackers

From Shinya Kato
Subject Re: CREATEROLE and role ownership hierarchies
Date
Msg-id f3c04e4e6c3e247215971e440c794e7d@oss.nttdata.com
Whole thread Raw
In response to Re: CREATEROLE and role ownership hierarchies  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: CREATEROLE and role ownership hierarchies  (Mark Dilger <mark.dilger@enterprisedb.com>)
List pgsql-hackers
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 that way,
> but the perceived value of the patch set likely depends on how much
> you see CREATEROLE in that light.)

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 with \du or pg_roles view.
2. Is it correct that REPLICATION/BYPASSRLS can be granted even if you 
are not a super user, but have CREATEROLE and REPLICATION/BYPASSRLS?
3. I think it would be better to have an "DROP ROLE [ IF EXISTS ] name 
[, ...] [CASCADE | RESTRICT]" like "DROP TABLE [ IF EXISTS ] name [, 
...] [ CASCADE | RESTRICT ]". What do you think?

-- 
Regards,

--
Shinya Kato
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: row filtering for logical replication
Next
From: Michael Paquier
Date:
Subject: Re: [PATCH] Fix memory corruption in pg_shdepend.c