Re: restrict global access to be readonly
От | Florian Pflug |
---|---|
Тема | Re: restrict global access to be readonly |
Дата | |
Msg-id | 1FBA31CF-4A5D-47ED-8D58-CE0EF4E66FB0@phlo.org обсуждение исходный текст |
Ответ на | Re: restrict global access to be readonly (David G Johnston <david.g.johnston@gmail.com>) |
Список | pgsql-hackers |
On Feb15, 2015, at 10:13 , David G Johnston <david.g.johnston@gmail.com> wrote: > happy times wrote >> Sure, we can utilize the runtime parameter >> default_transaction_read_only, however, it does not restrict user from >> changing transaction attribute to non-readonly mode, so is not safe. > > ISTM that implementing a means to make this setting only super-user > changeable would be a quick(er) solution to the problem - the decision as to > what to disallow is already decided. > > It seems like it would have to be a separate GUC but it would require any > new SQL but would simply leverage the existing settings system to setup > database-user values that only a super-user can change. I've wished for a way prevent regular users for changing specific settings in the past. Maybe we could have ALTER DATABASE <database> FORCE <parameter> TO <value> ALTER ROLE <role> [ IN DATABASE <db> ] FORCE <parameter> TO <value> In postgresql.conf, we could use a syntax like parameter =!= value to indicate that the parameter value can only be changed by super-users. We' have to figure out what happens if a database- or role-specific FORCEd setting attempts to override a value already FORCEd in postgresql.conf. Ideally, we'd allow database- or role-specific settings created by super-users to override previously FORCEd values, but that would require us to store the role that creates such settings in pg_db_role_setting. For SET clauses attached to functions, we'd complain if they attempt to change a FORCEd value, unless they are called by a super-user, or are marked SECURITY DEFINER and owned by a super-user. best regards, Florian Pflug
В списке pgsql-hackers по дате отправления: