Re: Additional role attributes && superuser review - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Additional role attributes && superuser review
Date
Msg-id 20150305164257.GA29780@tamriel.snowman.net
Whole thread Raw
In response to Re: Additional role attributes && superuser review  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
* Peter Eisentraut (peter_e@gmx.net) wrote:
> On 2/28/15 10:10 PM, Stephen Frost wrote:
> > * Adam Brightwell (adam.brightwell@crunchydatasolutions.com) wrote:
> >> I have attached and updated patch for review.
> >
> > Thanks!  I've gone over this and made quite a few documentation and
> > comment updates, but not too much else, so I'm pretty happy with how
> > this is coming along.  As mentioned elsewhere, this conflicts with the
> > GetUserId() to has_privs_of_role() cleanup, but as I anticipate handling
> > both this patch and that one, I'll find some way to manage. :)
> >
> > Updated patch attached.  Barring objections, I'll be moving forward with
> > this soonish.  Would certainly appreciate any additional testing or
> > review that you (or anyone!) has time to provide.
>
> Let's move this discussion to the right thread.

Agreed.

> Why are we not using roles and function execute privileges for this?

There isn't a particular reason not to, except that the existing checks
are in C code and those would need to be removed and the permission
changes done at initdb time to revoke EXECUTE from PUBLIC for these
functions.  Further, as you pointed out, we'd need to dump out the
permissions for the catalog tables and functions with this approach.  I
don't expect that to be too difficult to do though.
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Proposal: knowing detail of config files via SQL
Next
From: Andrew Gierth
Date:
Subject: Re: contraints_exclusion fails to refute simple condition