> > As I understand it, all slon daemons log into the appropriate Postgres
> > databases using the login and password that is indicated in the
> STORE_PATH()
> > line in the slonik script.  If the username given does not have
> superuser
> > access then the slon daemon will not get superuser access, slon just
> gets
> > the rights for that username.
> 
> No slon process ever updates any of the remote databases at all. They
> only ever insert, update and delete against the nodes local database. If
> it makes you feel better, you can put another user into the path info
> and set that user up for read only access of the slony schema. It should
> still work.
> 
> But keep in mind that all slon daemons simply do whatever they are told
> in the events they receive. So even without remote superuser access, an
> attacker can do almost all the damage he wants by simply injecting
> events into the compromised database. The events will be read by the
> slon daemons of the other nodes and they then do the damage on behalf of
> the attacker.
> 

Yes, but each slon daemon on each node still has to log into the local
Postres database to perform the insert/update/delete/whatever actions that
it sees arriving as events from the other databases, and for this it needs a
username+password.  Hence, each slon daemon is logging in with an
appropriate set of restricted privileges for its node.  Malicious events are
can still inserted on a remote compromised node, and get copied over to the
local node.  When the slon daemon tries (in good faith) to perform the
appropriate commands that it believes are necessary to replicate the events
in its node, the user the slon is logged in as may not have the rights to
perform the command.  Postgres itself will therefore reject the command.

This isn't a perfect solution.  A table that is a target of a replication
can still be maliciously be over-written.  On the other hand, a table that
is only ever replicated from (and never replicated to) should never need
write permission granted to the slon user.  Hence, even if malicious events
are injected, (e.g. explicit delete of data in the table) and the local slon
daemon tries to replicate it, then this command will be rejected on the
master database, thus protecting the true source of the data.  The tables on
other databases which were replication targets can still be corrupted, but
you don't suffer the risk of total data loss that you would have otherwise.