Re: role self-revocation
От | Mark Dilger |
---|---|
Тема | Re: role self-revocation |
Дата | |
Msg-id | EED0141C-060C-47E5-987D-0B19DC45739D@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: role self-revocation (Mark Dilger <mark.dilger@enterprisedb.com>) |
Список | pgsql-hackers |
> On Mar 7, 2022, at 12:03 PM, Mark Dilger <mark.dilger@enterprisedb.com> wrote: > > Right, but with a reflexive self-admin-option, we could document that it works in a non-inherited way. We'd just be sayingthe current hard-coded behavior is an option which can be revoked rather than something you're stuck with. We could also say that the default is to not have admin option on yourself, with that being something grantable, but thatis a larger change from the historical behavior and might have more consequences for dump/restore, etc. My concern about just nuking self-admin is that there may be sites which use self-admin and we'd be leaving them withouta simple work-around after upgrade, because they couldn't restore the behavior by executing a grant. They'd haveto more fundamentally restructure their role relationships to not depend on self-admin, something which might be harderfor them to do. Perhaps nobody is using self-admin, or very few people are using it, and I'm being overly concerned. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: