Re: superusers are members of all roles?
От | Andrew Dunstan |
---|---|
Тема | Re: superusers are members of all roles? |
Дата | |
Msg-id | 4D9DA78C.6030604@dunslane.net обсуждение исходный текст |
Ответ на | Re: superusers are members of all roles? (Christian Ullrich <chris@chrullrich.net>) |
Ответы |
Re: superusers are members of all roles?
|
Список | pgsql-hackers |
On 04/07/2011 07:33 AM, Christian Ullrich wrote: > * Andrew Dunstan wrote: > >> On 04/07/2011 03:48 AM, Alastair Turner wrote: > >>> Is the solution possibly to assign positive entries on the basis of >>> the superuser being a member of all groups but require negative >>> entries to explicitly specify that they apply to superuser? > >> I think that's just about guaranteed to produce massive confusion. +foo >> should mean one thing, regardless of the rule type. I seriously doubt >> that very many people who work with this daily would agree with Tom's >> argument about what that should be. > > What about adding a second group syntax that only evaluates explicit > memberships? That way, everyone could pick which behavior they liked > better, and Alastair's suggestion could be done that way, too: > > host all *personae_non_gratae 0.0.0.0/0 reject > host all +foo 0.0.0.0/0 md5 > > If, as Josh said, few users even know about the old syntax, there > should not be much potential for confusion in adding a new one. I thought about that. What I'd like to know is how many people actually want and use and expect the current behaviour. If it's more than a handful (which I seriously doubt) then that's probably the way to go. Otherwise it seems more trouble than it's worth. > > Additionally, most things that can be done with groups in pg_hba.conf > can also be done using CONNECT privilege on databases. In my case this won't work at all, since what I need is to allow the group access on a hot standby but prevent it on the master, and the CONNECT privs will be the same on both. We also don't have negative privileges analogous to "reject" lines. cheers aqndrew
В списке pgsql-hackers по дате отправления: