On 1/31/2007 12:51 PM, Christopher Browne wrote: > 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?
It especially means that superuser connections don't go over the wire, but stay inside the box. And yes, it is correct. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] # _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
