Re: CATUPDATE confusion?
От | Peter Eisentraut |
---|---|
Тема | Re: CATUPDATE confusion? |
Дата | |
Msg-id | 54F2376E.9080501@gmx.net обсуждение исходный текст |
Ответ на | Re: CATUPDATE confusion? (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: CATUPDATE confusion?
|
Список | pgsql-hackers |
On 2/25/15 10:05 PM, Stephen Frost wrote: > * Peter Eisentraut (peter_e@gmx.net) wrote: >> On 2/25/15 3:39 PM, Stephen Frost wrote: >>>> I'd get rid of that whole check, not just replace rolcatupdate by rolsuper. >>> >>> Err, wouldn't this make it possible to grant normal users the ability to >>> modify system catalogs? I realize that they wouldn't have that >>> initially, but I'm not sure we want the superuser to be able to grant >>> that to non-superusers.. >> >> Why not? I thought we are trying to get rid of special superuser behavior. > > Agreed, but I'd also like to get rid of any reason, beyond emergency > cases, for people to modify the catalog directly. There's a few places > which we aren't yet doing that, but I'd rather fix those cases than > encourage people to give out rights to modify them and end up making > things like: > > "UPDATE pg_database SET datallowconn = false where datname = 'xyz';" > > an accepted interface. I'm not sure those things are related. Getting rid of the *reasons* for updating catalogs directly might be worthwhile, but I don't see why we need to install (or maintain) a special invisible permission trap for it. We have a permission system, and it works pretty well. The Unix kernels don't have special traps for someone to modify /etc/shadow or similar directly. That file has appropriate permissions, and that's it. I think that works pretty well.
В списке pgsql-hackers по дате отправления: