Re: CREATEROLE and role ownership hierarchies
От | Shinya Kato |
---|---|
Тема | Re: CREATEROLE and role ownership hierarchies |
Дата | |
Msg-id | f3c04e4e6c3e247215971e440c794e7d@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: CREATEROLE and role ownership hierarchies (Mark Dilger <mark.dilger@enterprisedb.com>) |
Ответы |
Re: CREATEROLE and role ownership hierarchies
|
Список | 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 по дате отправления: