OK

Since I'm the one pushing for it and I don't really know Slony, it will take
me some time before I can put together a solid proposal for what could be
done.  I'll take the action, however, and see what I can come up with.

If there is any internal documentation on how Slony works then please pass
it my way.  I'm dredging with Google to get my hands on everything I can
however, so if all documentation is in out there somewhere then I'll
probably find it (or rather, Google will probably find it...).

If I have the occasional question, would you like me to mail you directly or
keep the mailing list on full copy ?

- R

> -----Original Message-----
> From: slony1-general-bounces at gborg.postgresql.org [mailto:slony1-general-
> bounces at gborg.postgresql.org] On Behalf Of Andrew Sullivan
> Sent: 23 January 2006 19:41
> To: slony1-general at gborg.postgresql.org
> Subject: Re: [Slony1-general] Security with slony
> 
> On Mon, Jan 23, 2006 at 07:10:40PM -0000, Roger Lucas wrote:
> > Perhaps the slony processes around the system could be given the
> credentials
> > for a restricted user and thus could not send administrative events
> (apart
> > from SYNC).  When something goes wrong then the sysadmin can provide the
> > credentials for a privileged user and make any required changes.  Upon
> > completion, the sysadmin restores the credentials for the user with
> > restricted privileges.
> 
> That was sort of what I had in mind for an acl approach.  Every node
> gets its own user.  That way, you just have a list of things that can
> originate from any given user.  Now, you want your slonik commands to
> come from a particular workstation, and always be injected at one
> (and only one) node?  Then you configure the ACL on every node except
> the injection site to refuse such commands, and you configure the
> nodes to accept such commands coming only from this or that node.
> 
> This has several problems I can think of.  You'll need to be
> perfectly certain of your listen paths.  I can think  of all sorts of
> ways this might break.  I also don't think it'd be a trivial amount
> of work to hack in (and an even less-trivial job to make it anything
> other than easy to circumvent).  But on the back of a napkin it looks
> implementable.  I'd be interested to see a real proposal.
> 
> A
> 
> --
> Andrew Sullivan  | ajs at crankycanuck.ca
> Information security isn't a technological problem.  It's an economics
> problem.
> 		--Bruce Schneier
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general