Re: Additional role attributes && superuser review

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Thu, Oct 16, 2014 at 11:24 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> > 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.
>
> I'm a little nervous that we're going to end up with a whole bunch of
> things with names like X_control, Y_operator, and Z_admin, which I
> think is particularly bad if we end up with a mix of styles and also
> bad (though less so) if we end up just tacking the word "operator"
> onto the end of everything.

Yeah, that's certainly a good point.

> I'd suggest calling these capabilities, and allow:
>
> GRANT CAPABILITY whatever TO somebody;

So, we went back to just role attributes to avoid the keyword issue..
The above would require making 'CAPABILITY' a reserved word, and there
really isn't a 'good' already-reserved word we can use there that I
found.

Also, role attributes aren't inheirited nor is there an 'ADMIN' option
for them as there is for GRANT- both of which I feel are correct for
these capabilities. Or, to say it another way, I don't think these
should have an 'ADMIN' option and I don't think they need to be
inheirited through role membership the way granted privileges are.

We could still use 'GRANT <keyword> whatever TO somebody;' without the
admin opton and without inheiritance, but I think it'd just be
confusing for users who are familiar with how GRANT works already.

Thanks!

Stephen