Where does medusa look for html files by default? I have regular old html files that I'd like to make available without fiddling with Zope. Is that possible?
On Mon, Jul 03, 2000 at 03:27:04PM -0400, Frank McGeough wrote:
Where does medusa look for html files by default? I have regular old html files that I'd like to make available without fiddling with Zope. Is that possible?
Not out of the box. ZServer, which is based on Medusa, doesn't support serving of HTML files from the local file system, it noly serves content out of Zope itself. There is a product on Zope.org called LocalFS that allows you to integrate filesystem based content into Zope though. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ | ZopeStudio: http://www.zope.org/Products/ZopeStudio -----------------------------------------------------
have regular old html files that I'd like to make available without fiddling with Zope. Is that possible?
Not out of the box. ZServer, which is based on Medusa, doesn't support serving of HTML files from the local file system, it noly serves content out of Zope itself.
Slightly off topic, but related. Does this mean that the everything on local file system is protected natively in zope. Short of things like buffer overflows. What I mean is, can I somehow muck up security in Zope and compromise my local system, or will only zope objects be affected? I'm an absolute newbie to zope, and still trying to get a handle on the architecture. Thanks, gary
Gary Shears wrote:
Slightly off topic, but related. Does this mean that the everything on local file system is protected natively in zope. Short of things like buffer overflows. What I mean is, can I somehow muck up security in Zope and compromise my local system, or will only zope objects be affected? I'm an absolute newbie to zope, and still trying to get a handle on the architecture.
As long as you don't use products that read and write arbitrary files (such as LocalFS), Zope doesn't provide any way to write to any directory but the "var" subdirectory (or if it does, it shouldn't and will be fixed.) So yes, Zope's architecture does provide decent isolation from the file system. Also keep in mind that Zope does not run as "root", so if you are running on a Unix-like system such as Linux, even if Zope were fully compromised an intruder would still have to find a security hole in something else before it's possible to write to arbitrary files. Shane
Also keep in mind that Zope does not run as "root", so if you are running on a Unix-like system such as Linux, even if Zope were fully compromised an intruder would still have to find a security hole in something else before it's possible to write to arbitrary files.
I just checked the perms on zope, and it's owned by root. Started it, looked at the processes owned by root (ps -u root) and 'python' shows up, with the same PID as Z2.pid. Is there an easy way to fix this? Thanks in advance. --gary
Gary Shears wrote:
Also keep in mind that Zope does not run as "root", so if you are running on a Unix-like system such as Linux, even if Zope were fully compromised an intruder would still have to find a security hole in something else before it's possible to write to arbitrary files.
I just checked the perms on zope, and it's owned by root. Started it, looked at the processes owned by root (ps -u root) and 'python' shows up, with the same PID as Z2.pid. Is there an easy way to fix this? Thanks in advance.
Run ps -ef|grep python or ps auxww|grep python (depending on your system; the latter is preferred). Zope usually runs two processes: a process manager and the real server. The process manager runs as root and the real server, which actually handles the connections and talks to the file system, has many threads. So, if configured correctly, you should see one python process running as root and several others running as nobody (or whataver you configured the user to be). The process manager just restarts the real server automatically when it dies. Shane
participants (4)
-
Frank McGeough -
Gary Shears -
Martijn Pieters -
Shane Hathaway