Skip site navigation (1) Skip section navigation (2)

Re: Connection limit and Superuser

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Connection limit and Superuser
Date: 2006-07-31 16:45:58
Message-ID: 60zmepk9ix.fsf@dba2.int.libertyrms.com (view raw or flat)
Thread:
Lists: pgsql-hackers
andrew(at)dunslane(dot)net (Andrew Dunstan) writes:
> Joshua D. Drake wrote:
>
>>
>>>
>>> As a protection against malice, yes. I think Rod was more
>>> interested in some protection against stupidity.
>>>
>>> Maybe the real answer is that Slony should connect as a
>>> non-superuser and call security definer functions for the
>>> privileged things it needs to do.
>>
>>
>> Wouldn't that break Slony's ability to connect to older postgresql
>> versions and replicate?
>>
>
> I don't know anything of Slony's internals, but I don't see why older
> versions should matter - Postgres has had security definer functions
> for every release that Slony supports. Maybe I'm missing something ...

Most of Slony-I's activities don't require superuser access.  The
usual thing that's running are SYNC events, and those merely require
write access to some internal Slony-I tables and write access to the
replicated tables on the subscribers.

The functions that do need superuser access are (basically)
 - subscribe set (needs to alter system tables)
 - execute script (ditto)

The trouble is that you in effect need to have that superuser up and
ready for action at any time in case it's needed, and it being that
needful, we basically use it all the time.

Perhaps it's worth looking at shoving the superuser stuff into
SECURITY DEFINER functions; that may be worth considering
post-1.2.0...
-- 
output = reverse("gro.gultn" "@" "enworbbc")
http://cbbrowne.com/info/multiplexor.html
Wow!  Windows  now can do  everything using shared library  DLLs, just
like Multics  did back in  the 1960s!  Maybe someday  they'll discover
separate processes and pipes, which came out in the 1970s!

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-07-31 17:06:04
Subject: Re: tg_trigtuple not NULL in AFTER STATEMENT triggers?
Previous:From: Jim C. NasbyDate: 2006-07-31 16:40:21
Subject: Re: [HACKERS] extension for sql update

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group