On Mon, Dec 27, 2010 at 09:32, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Thu, 2010-12-23 at 10:53 +0100, Magnus Hagander wrote:
>
>> Here's a patch that changes walsender to require a special privilege
>> for replication instead of relying on superuser permissions. We
>> discussed this back before 9.0 was finalized, but IIRC we ran out of
>> time. The motivation being that you really want to use superuser as
>> little as possible - and since being a replication slave is a read
>> only role, it shouldn't require the maximum permission available in
>> the system.
>
> Is backup part of this new privilege, or not?
The "integrated base backup", once we have that, that's based on the
walsender protocol? yes.
pg_dump style backups? No.
> I think if we're going to introduce a new level of privilege, then we
> should introduce all delegatable privs in one software release. Much
> better than having someone think up a new delegatable priv each release
> for next 5 years.
>
> Other possible ones include unsafe PL creation, seeing logged SQL etc..
That's certainly an option, but that means someone would have to come
up with a list ;) And one that's reasonable - for example, "unsafe pl
creation" is from a security perspective (which is the only thing
that's really intersting here) the same as superuser.
Seeing logged SQL isn't - but being able to filter the logfiles on
that requires a *lot* more than just defining a security privilege. If
we mean "arbitrary log file reading", the easiest way to fix that
would be to stop checking for superuser permissions in the
read-file-function, and instead use the permissions *on the function*
to control it. In fact, that is something that we could (should?) do
for a bunch of other functions as well, so that we can in that way
provide much more granular permissions level than just blanked
assigning of privileges.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/