Perhaps the question could be put a different way:

"How can we make minimal changes to Slony so that administrative events can
be disabled for particular Postgres users?"

Perhaps the slony processes around the system could be given the credentials
for a restricted user and thus could not send administrative events (apart
from SYNC).  When something goes wrong then the sysadmin can provide the
credentials for a privileged user and make any required changes.  Upon
completion, the sysadmin restores the credentials for the user with
restricted privileges.


> -----Original Message-----
> From: Christopher Browne [mailto:cbbrowne at ca.afilias.info]
> Sent: 23 January 2006 19:01
> To: Jim C. Nasby
> Cc: Roger Lucas; slony1-general at gborg.postgresql.org
> Subject: Re: [Slony1-general] Security with slony
> 
> "Jim C. Nasby" <jnasby at pervasive.com> writes:
> > On Mon, Jan 23, 2006 at 04:48:14PM -0000, Roger Lucas wrote:
> >> > No, you seem to misunderstand.  Slonik injects events, just like any
> >> > other kinds of event, into the replica stream.
> >>
> >> That confuses me, as I had read the information below to imply that
> >> the network configuration commands (i.e. control messages from the
> >> "administrative workstation" that set up the topology of the
> >> replication network) were sent "out of band" using different links
> >> which could then be shut down when not required.
> >
> > I'm wondering if it would be possible to add the idea of
> > 'administrative command'. My understanding is that very few things
> > require superuser access, so it might be possible to put more
> > stringent requirements on their use. It's much more likely that
> > these commands do not need to run without human intervention, so
> > (for example), it might be far more practical for these commands to
> > require the user to supply a password to gain access to the SU
> > account on all the nodes; or perhaps the commands are run from a
> > secured workstation that has the proper credentials in ~/.pgpass. I
> > realize that the requirement for these commands to happen as part of
> > the replication stream (in the correct order with everything else)
> > complicates this, but it should be possible to allow for a
> > SU-enabled slon process to connect to remote machines via an SU
> > account to process those admin commands and then be shut-down again
> > after they were finished.
> 
> Well, that seems a *less* interesting question to me than you might
> think.
> 
> As far as I am concerned, the only "non-administrative event" (minor
> distinction from "command") is Slony-I's own "SYNC" event.
> 
> Every other event is "administrative," whether it needs superuser
> access or not.
> 
> There's a boatload of Slonik commands; they are all "administrative,"
> every one of them.
> 
> You'll need to run Slonik when:
>  - Servers go unstable and require special maintenance
>  - Software changes, thereby changing schemas
>  - New servers come along
> 
> Those are definitely "out of the ordinary" events.
> 
> On the average day, when Slony-I is operating, you don't need to use
> any of them.  For the average TLD registry, we don't need to fiddle
> with database schemas even as often as once a month, so any day when
> we run Slonik represents a pretty unusual day.  And that is doubtless
> true for most Slony-I users.
> 
> It wouldn't be an outrageous idea to have more stringent user
> capabilities requirements for the user that is used for running
> Slonik.
> 
> Unfortunately, this turns out to be a pretty banal result, because it
> does not suffice to "make slonik run special."
> 
> The trouble with that idea is that a lot of the "administrative" work
> is done indirectly, by the slon processes.  The slon also needs
> "superuser" access because much of the Slonik work gets passed on to
> the slon.
> 
> The average SYNC event (which is the only non-administrative event
> that there is!!!) doesn't need superuser access for the slon.  But the
> slon-based processing of every other event *potentially* means that
> every slon needs superuser access in order to invoke those other
> events.
> --
> "cbbrowne","@","ca.afilias.info"
> <http://dba2.int.libertyrms.com/>
> Christopher Browne
> (416) 673-4124 (land)