What is the appropriate way to install Zope 2.7 beta3 and ZEO? I did the "./configure make make install" routine, but how shold you do the rest to get Zope and ZEO running? I noticed mkzeoinstance.py and mkzopeinstance.py. I guess I should run those, but I don't find any docs describing them and they seem new so they are not mentioned in The Zope Book. In what order should I run mkzeoinstance.py and mkzopeinstancepy, does the order matter? I found a site saying that you could run "mkzopeinstance --zeo", but that argument seem to be missing. So therefore I wonder, do I have to tell Zope about ZEO? And what directories should I specify when running mkzeoinstance and mkzopeinstance? I want a nice directory structure. Google couldn't help me, or atleast it didn't want to at the moment I was searching :-) Tim
At 11:13 PM 11/18/2003 +0100,Tim wrote:
What is the appropriate way to install Zope 2.7 beta3 and ZEO? I did the "./configure make make install" routine, but how shold you do the rest to get Zope and ZEO running?
Hot off the presses on Zope.org, here's this link: at least a good start. http://zope.org/Members/kedai/useZeoZope =Paul
I have several sites running next to each other, each in its own folder, all in a folder called "sites", located under root, like this... / /sites /foo /boo /moo If I am viewing http://foo.com, I see the content from the folder sites/foo. But if I type http://foo.com/sites/boo, I get to view the content from (duh) sites/boo instead of saying 404: Stuff Not Found, or 666: Stay the Heck Outa Here (either of those would be fine, I think) Any ideas how I stop this security problem, this "acquisition leak"? In what folder (sites? foo?) do I tweak the security settings, and how? I tried re-reading the Zope Book chapter about Security, and it is great for User management, but not for stopping acquisition when you don't want it to acquire. A suggestion from the IRC gang was that this could be a VHM bug, but that's not it because it also happens on naked Zope going in through port 8080, where VHM would not be involved. =Paul
Paul Howell wrote:
I have several sites running next to each other, each in its own folder,
The easy answer is, "don't do that." If you want data integrity between virtualhosts, don't store them in the same zope instances. The complicated answer is to use a Site Access Rule to stop undesired acquisition. No I don't have any examples because I've never seen it done. Its the solution has been offered up before for this problem but nobody ever seems to pony up an actual example of working code. Perhaps it doesn't matter anyway as Site Access Rules are trivial to bypass and probably shouldn't be used for security (or anywhere they must reliably trigger). -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa
On Tue, 2003-11-18 at 18:41, Jamie Heilman wrote:
Paul Howell wrote:
I have several sites running next to each other, each in its own folder,
The easy answer is, "don't do that." If you want data integrity between virtualhosts, don't store them in the same zope instances.
That is the best available answer I'm aware of if security matters and you're hosting multiple sites with anonymous access. But if it doesn't have to be really tight and you prefer the simplicity of VHM mappings, a trick you could use is to salt each virtual root with error-returning methods that have the same name as your other roots. site_roots/ foo/ boo moo boo/ foo moo moo/ foo boo This isn't bulletproof or anything, but it may be good enough to prevent accidents and discourage experimentation. Appropriateness depends on your requirements. HTH, Dylan
-----Original Message----- From: zope-bounces@zope.org [mailto:zope-bounces@zope.org]On Behalf Of Dylan Reinhardt Sent: 19. november 2003 04:35 To: Jamie Heilman Cc: Zope Users Subject: Re: [Zope] acquisition and security
On Tue, 2003-11-18 at 18:41, Jamie Heilman wrote:
Paul Howell wrote:
I have several sites running next to each other, each in its own folder,
The easy answer is, "don't do that." If you want data integrity between virtualhosts, don't store them in the same zope instances.
That is the best available answer I'm aware of if security matters and you're hosting multiple sites with anonymous access.
But if it doesn't have to be really tight and you prefer the simplicity of VHM mappings, a trick you could use is to salt each virtual root with error-returning methods that have the same name as your other roots.
site_roots/ foo/ boo moo boo/ foo moo moo/ foo boo
This isn't bulletproof or anything, but it may be good enough to prevent accidents and discourage experimentation. Appropriateness depends on your requirements.
HTH,
Dylan
Hi all, sorry, but this is the most silly thing i have seen so far ! (and a bit annoying.....) That a folder aquires its sibling folders complete tree. I have several cmf-sites in the root of a zope-instance, which is hosted not by myself. I can actually write for instance www.dom1.com/dom2siterootfolder/dom2content and get content from site dom2.com shown in dom1.com No other way to stop aq. from its megalomania ? (its not a security issue, since the stuff has to be public, but its silly, and dangerous, inviting stupid things to happen.) greetings, Sune
Sune BrXndum WXller wrote:
sorry, but this is the most silly thing i have seen so far ! (and a bit annoying.....) That a folder aquires its sibling folders complete tree. I have several cmf-sites in the root of a zope-instance, which is hosted not by myself. I can actually write for instance www.dom1.com/dom2siterootfolder/dom2content and get content from site dom2.com shown in dom1.com
No other way to stop aq. from its megalomania ?
(its not a security issue, since the stuff has to be public, but its silly, and dangerous, inviting stupid things to happen.)
Acquisition is fundamental to Zope, and this is just the way things work. And one of the features of this is that it doesn't insulate between VHM sites. It may be a misfeature, but it is performing as designed. Someone sufficiently clever and knowledgable (or sufficiently motivated) about the acquisition machinery could probably figure out a way around this. It should be easy to create a folder that does not acquire higher than itself. And probably in all of 20 lines of filesystem code, including boilerplate. Arranging things such that only acquisition to folders mapped in a VHM is stopped, and doing it all in the VHM (so generality of mapping targets is preserved) would pose a larger problem. Still doable, I think, but I'm not about to go doing it for fun (it doesn't really bother me that much.) --jcc -- "My point and period will be throughly wrought, Or well or ill, as this day's battle's fought."
-----Original Message----- From: zope-bounces@zope.org [mailto:zope-bounces@zope.org]On Behalf Of J. Cameron Cooper Sent: 20. november 2003 00:10 To: Sune BrXndum WXller Cc: zope@zope.org Subject: Re: [Zope] acquisition and security
Sune BrXndum WXller wrote:
sorry, but this is the most silly thing i have seen so far ! (and a bit annoying.....) That a folder aquires its sibling folders complete tree. I have several cmf-sites in the root of a zope-instance, which is hosted not by myself. I can actually write for instance www.dom1.com/dom2siterootfolder/dom2content and get content from site dom2.com shown in dom1.com
No other way to stop aq. from its megalomania ?
(its not a security issue, since the stuff has to be public, but its silly, and dangerous, inviting stupid things to happen.)
Acquisition is fundamental to Zope, and this is just the way things work. And one of the features of this is that it doesn't insulate between VHM sites. It may be a misfeature, but it is performing as designed.
Someone sufficiently clever and knowledgable (or sufficiently motivated) about the acquisition machinery could probably figure out a way around this. It should be easy to create a folder that does not acquire higher than itself. And probably in all of 20 lines of filesystem code, including boilerplate. Arranging things such that only acquisition to folders mapped in a VHM is stopped, and doing it all in the VHM (so generality of mapping targets is preserved) would pose a larger problem. Still doable, I think, but I'm not about to go doing it for fun (it doesn't really bother me that much.)
Don't get me wrong, acquisition *is* quite clever, but as a beginner I get a bit frustrated sometimes with zope, all those unexpected side effects. Generally speaking I would prefer to have a greater amount of control over which urls that are valid and which that return a 404. To follow your suggestion : I would have to look into making a folder with explicit rather than implicit acquisition, by inheriting Acquisition.Explicit (?) /sune
Jamie Heilman wrote at 2003-11-18 18:41 -0800:
... Perhaps it doesn't matter anyway as Site Access Rules are trivial to bypass and probably shouldn't be used for security (or anywhere they must reliably trigger).
How do you bypass an AccessRule? -- Dieter
On Wed, 2003-11-19 at 11:16, Dieter Maurer wrote:
Jamie Heilman wrote at 2003-11-18 18:41 -0800:
... Perhaps it doesn't matter anyway as Site Access Rules are trivial to bypass and probably shouldn't be used for security (or anywhere they must reliably trigger).
How do you bypass an AccessRule?
You add _SUPPRESS_ACCESSRULE to the URL. Dylan
participants (7)
-
Dieter Maurer -
Dylan Reinhardt -
J. Cameron Cooper -
Jamie Heilman -
Paul Howell -
Sune Br�ndum W�ller -
Tim Terlegård