http://www.slony.info/bugzilla/show_bug.cgi?id=142

--- Comment #5 from Steve Singer <ssinger at ca.afilias.info> 2010-08-05 06:40:13 PDT ---
enable_indexes_on_table  and disable_indexes_on_table are declared with
SECURITY DEFINER.   This means that they run with the permissions of the user
that creates the function (a database owner or superuser if you want things to
work).

The problem is that we are not restricting who can call these functions. This
means that ANY user can enable the indexes on ANY table at will.  This can't be
a good idea.

If we are going to do this I think we need to introduce the concept of a slony
replication role/user,

The 'admin conninfo' for slonik commands that involve installing, uninstalling,
or upgrading a node probably need to be done as superuser/database owner.  
As part of the installation process we would need to create a slony replication
role/user. (note people might have multiple slony replicated database as part
of the same postgresql cluster, actually slony even allows multiple 'slony
clusters' as part of the same pg database). 

The slon daemons would then need to use this replication user when they connect
to their local nodes.   The conninfo data for remote databases (store path) can
be even less priviledged.

I don't think we can put this patch into head/master until we can lock down
those functions.

-- 
Configure bugmail: http://www.slony.info/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.