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: [EMAIL PROTECTED] [mailto:slony1-general- > [EMAIL PROTECTED] On Behalf Of Andrew Sullivan > Sent: 23 January 2006 19:41 > To: [email protected] > 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 | [EMAIL PROTECTED] > Information security isn't a technological problem. It's an economics > problem. > --Bruce Schneier > _______________________________________________ > Slony1-general mailing list > [email protected] > http://gborg.postgresql.org/mailman/listinfo/slony1-general _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
