Re: Additional role attributes && superuser review - Mailing list pgsql-hackers
| From | Adam Brightwell |
|---|---|
| Subject | Re: Additional role attributes && superuser review |
| Date | |
| Msg-id | CAKRt6CRoMQNHMKJEisTAdpJtjhvuMAaNtk7A69oERO3ARMs0yw@mail.gmail.com Whole thread Raw |
| In response to | Re: Additional role attributes && superuser review (Magnus Hagander <magnus@hagander.net>) |
| Responses |
Re: Additional role attributes && superuser review
(Stephen Frost <sfrost@snowman.net>)
|
| List | pgsql-hackers |
Magnus,
Thanks for the feedback.
Upon re-reading it (and other discussions around it) I believe that I must have misinterpreted. Initially, I read it to mean that we needed the following separate permissions.
* BACKUP - allows role to perform backup operations (as originally proposed)
--
BACKUP - allows role to perform pg_dump* backups of whole database.I'd suggest it's called DUMP if that's what it allows, to keep it separate from the backup parts.
Makes sense to me.
That seems really bad names, IMHO. Why? Because we use WAL and XLOG throughout documentation and parameters and code to mean *the same thing*. And here they'd suddenly mean different things. If we need them as separate privileges, I think we need much better names. (And a better description - what is "xlog operations" really?)
Fair enough, ultimately what I was trying to address is the following concern raised by Alvaro:
"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."
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."
Upon re-reading it (and other discussions around it) I believe that I must have misinterpreted. Initially, I read it to mean that we needed the following separate permissions.
1) ability to pg_dump
2) ability to start/stop backups
3) ability to execute xlog related functions
When indeed, what it meant was to have the following separate (effectively merging #2 and #3):
1) ability to pg_dump
2) ability to start/stop backups *and* ability to execute xlog related functions.
My apologies on that confusion.
Given this clarification:
I think #1 could certainly be answered by using DUMP. I have no strong opinion in either direction, though I do think that BACKUP does make the most sense for #2. Previously, Stephen had mentioned a READONLY capability that could effectively work for pg_dump, though, Jim's suggestion of keeping 'read-all' separate from 'ability to pg_dump' seems logical. In either case, I certainly wouldn't mind having a wider agreement/consensus on this approach.
So, here is a revised list of proposed attributes:
* LOG - allows role to rotate log files - remains broad enough to consider future log related operations
* DUMP - allows role to perform pg_dump* backups of whole database
* MONITOR - allows role to view pg_stat_* details (as originally proposed)
* PROCSIGNAL - allows role to signal backend processes (as originally proposed)well
Thanks,
Adam
Adam Brightwell - adam.brightwell@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
pgsql-hackers by date: