On 05/15/2013 01:51 PM, Brian Fehrle wrote:
> Hi All,
>
> I have a slony cluster running on slony 2.1.0 (Have tested this
> situation on 2.1.3 also). This cluster is replicating a drupal database,
> which preforms truncates on some of the cache tables periodically. When
> the truncates execute, they fire the log_truncate trigger in slony,
> which immediatly errors due to no select permissions on the sl_table
> relation in the slony cluster.
>
> In normal events (inserts, updates, deletes), the user doesn't need any
> permissions granted in the slony schema in order for the event trigger
> to log the event into sl_log_1, etc.
>
> So is this a design decision, making truncates on slony tables only be
> able to be executed by superusers in the database?

I would call it a bug. The truncate trigger should be "security 
definer", like the log trigger and several other functions are.


Jan

>
> I've got it working in a testing environment by granting the following:
> grant select on _slony.sl_table to user;
> grant insert on _slony.sl_log_status to user;
> grant insert on _slony.sl_log_1 to user;
> grant insert on _slony.sl_log_2 to user;
> grant usage on _slony.sl_action_seq to user;
>
> However I don't like the idea of either A. granting these permissions to
> slony tables or B. making my drupal user a 'superuser' to get around it.
> Are those my only two options here to allow truncates to work?
>
> Thanks,
> - Brian F
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
>


-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin