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?  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Looking for Intro to Hacking teacher for pgCon
Следующее
От: Venkata Balaji N
Дата:
Сообщение: Re: Streaming replication and WAL archive interactions