Re: Additional role attributes && superuser review
От | Stephen Frost |
---|---|
Тема | Re: Additional role attributes && superuser review |
Дата | |
Msg-id | 20141016154751.GE28859@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Additional role attributes && superuser review (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Additional role attributes && superuser review
(Jim Nasby <Jim.Nasby@BlueTreble.com>)
|
Список | pgsql-hackers |
Alvaro, * Alvaro Herrera (alvherre@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Petr Jelinek (petr@2ndquadrant.com) wrote: > > > On 15/10/14 07:22, Stephen Frost wrote: > > > > First though, the new privileges, about which the bikeshedding can > > > > begin, short-and-sweet format: > > > > > > > > BACKUP: > > > > pg_start_backup() > > > > pg_stop_backup() > > > > pg_switch_xlog() > > > > pg_create_restore_point() > > > > > > As others have commented, I too think this should support pg_dump. > > > > I'm uttly mystified as to what that *means*. Everyone asking for it is > > great but until someone can define what "support pg_dump" means, there's > > not much progress I can make towards it.. > > To me, what this repeated discussion on this particular BACKUP point > says, is that the ability to run pg_start/stop_backend and the xlog > related functions should be a different privilege, i.e. something other > than BACKUP; because later we will want the ability to grant someone the > ability to run pg_dump on the whole database without being superuser, > and we will want to use the name BACKUP for that. So I'm inclined to > propose something more specific for this like WAL_CONTROL or > XLOG_OPERATOR, say. Ok. Not sure that I see 'XLOG_OPERATOR' as making sense for 'pg_start_backup' though, and I see the need to support pg_dump'ing the whole database as a non-superuser being more like a 'READONLY' kind of role. We've actually already looked at the notion of a 'READONLY' or 'READALL' role attribute and, well, it's quite simple to implement.. We're talking about a few lines of code to implicitly allow 'USAGE' on all schemas, plus a minor change in ExecCheckRTEPerms to always (or perhaps *only*) include SELECT rights. As there's so much interest in that capability, perhaps we should add it.. One of the big question is- do we take steps to try and prevent a role with this attribute from being able to modify the database in any way? Or would this role attribute only ever increase your rights? > > pg_dump doesn't require superuser rights today. If you're looking for a > > role which allows a user to arbitrairly read all data, fine, but that's > > a different consideration and would be a different role attribute, imv. > > If you'd like the role attribute renamed to avoid confusion, I'm all for > > that, just suggest something. > > There. Fair enough, just don't like the specific suggestions. :) In the docs, we talk about pg_start_backup being for 'on-line' backups, perhaps we use ONLINE_BACKUP ? Or PITR_BACKUP ? > (Along the same lines, perhaps the log rotate thingy that's being > mentioned elsewhere could be LOG_OPERATOR instead of just OPERATOR, to > avoid privilege "upgrades" as later releases include more capabilities > to the hypothetical OPERATOR capability.) I'd be fine calling it LOG_OPERATOR instead, sure. Thanks! Stephen
В списке pgsql-hackers по дате отправления:
Следующее
От: Stephen FrostДата:
Сообщение: Re: Directory/File Access Permissions for COPY and Generic File Access Functions