Hi Andrew,

Thanks for your reply.  I have looked at log shipping in detail, but our
situation makes it inappropriate (I think).  I will explain a bit more about
our network:

Our primary (and secure) server holds the master configuration tables.
These change every so often, but changes must be propagated ASAP to the
multiple remote sites (which are considered partially secure).

The remote sites are busy and each site has its own unique namespace where
it writes log and state information.  We pull these namespaces back to our
primary site so that we have all the log and state information locally.

The network topology is very stable.  Once we have set up the node
master-slave topologies we want to:
 - Absolutely lock this configuration in concrete
 - Absolutely ensure that slony can never write to the master "primary"
namespace

Looking at the slony documentation, it suggests that slonik would not be run
very often in the above scenario, so we could use ssltunnels to link the
sites for the configuration commands and then remove these tunnels to
prevent the node configuration from changing.  Firewalling of all incoming
SSL tunnels to the master node would prevent the slaves from triggering any
changes by themselves.  This is an excellent start.

I would have no problem explicitly granting access to specific tables to
allow slonik to change its configuration should I need to reconfigure the
network for any reason and then revoking these permissions after the action
was complete.  The key here is that the super user which grants the
privileges would have a unique password on each node, so no malicious user
could use the password information gleaned from one node to change the
privileges on a different node.  To allow the tables to be locked down in
this way, I would need to know which tables slony needs write access to and
under what conditions.

I appreciate your comment about "vi" below.  I think that the above scenario
is different, however, as I don't care if a malicious user completely wrecks
a particular node.  I am assuming that if they break into a node, then they
can and will do this anyhow.  By making each node have a unique set of
passwords, however, they cannot use their knowledge from one node to change
the configuration of a different node - their passwords etc just won't let
them log into the other node to make the privilege changes required to allow
slonik to reconfigure the network topology.

I hope the above makes sense and appreciate your thoughts/suggestions.

Best regards,

Roger

> -----Original Message-----
> From: slony1-general-bounces at gborg.postgresql.org [mailto:slony1-general-
> bounces at gborg.postgresql.org] On Behalf Of Andrew Sullivan
> Sent: 23 January 2006 12:03
> To: slony1-general at gborg.postgresql.org
> Subject: Re: [Slony1-general] Security with slony
> 
> On Sat, Jan 21, 2006 at 05:27:40PM -0000, Roger Lucas wrote:
> > Ideally, I am looking for information on what privileges and commands
> Slony
> > needs for the configuration and replication operations for the master
> and
> > slave nodes in the system.  I can go through the code, but that is going
> to
> > take some time, so I was hoping that someone might know the answers or
> point
> > me to some more detailed documentation.
> 
> I've sometimes thought that it would be possible to split things up
> this way:
> 
> 1.	A super-user role for setup and configuration.
> 2.	A regular user for normal operation.
> 
> The problem would be that, as soon as any operation involving tables
> happened, you'd need some way of automatically promoting the "regular
> user" to superuser status.  So this would turn out actually to be no
> security at all.  It's like giving limited sudo access to some user,
> but one of the commands is "vi".  Since the user can escape to the
> shell, you've effectively just given them the keys anyway, although
> at one level of indirection.
> 
> Your better bet would be to use the log shipping mechanism available
> in 1.1.  It solves this problem for you.
> 
> A
> 
> --
> Andrew Sullivan  | ajs at crankycanuck.ca
> This work was visionary and imaginative, and goes to show that visionary
> and imaginative work need not end up well.
> 		--Dennis Ritchie
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general