On 2/3/2006 1:43 PM, Roger Lucas wrote:

> 
>> > 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.

Slon needs superuser access including catalog update permission on the 
local database. Otherwise it can neither perform the commands required 
to subscribe to a set, nor could it ever do anything like failover or 
switchover.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #