Jan Wieck <[EMAIL PROTECTED]> writes: > Thus, the db user connecting from slon to the local node has to be a > superuser at some times and I don't see the benefit of adding more > complexity here. Slon will know the user and password (if required). > > Where the superuser definitely isn't required is for all the remote > connections. Since slon never even updates on a remote connection, one > could go so far and grant select privileges on the slony tables only. > And you know what the good news is? All that's required to do so is > creating the user, doing the grant's and using that user in the login > info in sl_path. We don't need to change a single line of code.
A useful observation emerges, I think... The connections that are stored in sl_path can *ALWAYS* be unprivileged users. They need *read* access solely to the tables in the replication schema/namespace. And they need enough privileges to be able to raise events; I'm not sure exactly what minimal permissions that requires. In contrast, the connections to the local node might always be privileged/superusers. Does that all sound correct? If that's correct, then some relatively simple user policies can cut down dramatically on the perceived need for use of superuser accounts. That doesn't go all the way to using a non-superuser as much as possible, but having an easy 80% step would be a nice thing, right? -- select 'cbbrowne' || '@' || 'ca.afilias.info'; <http://dba2.int.libertyrms.com/> Christopher Browne (416) 673-4124 (land) _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
