Hi Craeg, Thanks for your reply... I'd have to respectfully disagree about ExternalFile only for developers because I think it has applications in a production environment as well. 1. Large files. I'd feel more comfortable storing multi-megabyte PDFs and video files in the Linux file system than in Zope for the reason that it would help reduce the unnecessary bloat that Data.fs can grow to. Keeping Data.fs' size in control is also important for backups and general maintenance. I think there is a default 2GB limit to Zope unless python was recompiled with a higher setting. 2. Integration. Being able to tap into the filesystem gives Zope a lot of flexibility when addressing some integration issues. 3. And like you said, most people use it for production anyway. :) For the sake of discussion, would a pre-registration of the ExternalFile-allowed directories, lead to better security? That way, administrators can set how secure/unsecure they want to get by explicitly specifying the folders ExternalFile is allowed to access. Thoughts? Jon --- Craeg K Strong <cstrong@arielpartners.com> wrote:
Yikes! Scary stuff.
However, here are some things to consider:
a) ExternalFile advertises itself as being a developers/ content authors tool, not really for production. Of course, most folks end up using it for production, anyway... ;-)
b) Once created, an ExternalFile cannot be retargetted to point to another file in the file system
c) The permission to create an ExternalFile instance is different than the permission to edit one. The permission to create an ExternalFile instance should be assigned judiciously...
d) the Zope server should be run as a user that has very limited permissions.
e) Even if a user *does* have permission to edit an ExternalFile, they only have whatever permission the user running the Zope server has. If the Zope user (usually "webserver" or something like that) does not have permission to write to /etc/passwd, it doesn't matter if you create an ExternalFile pointing to it, you still can't write to it...
However, the points you raise are valid, as they are Zope-specific, and the zope user "webserver" *would* probably have permission to do your (1) and (2) examples.
What would you recommend? Perhaps there should be a predefined list of "forbidden" directories for ExternalFiles? The problem is that-- in the development scenario-- the very things you mention below might be what you legitimately *want* to do as a developer.
Well, thanks for pointing this out. Let's continue the conversation a bit, perhaps a good solution will reveal itself (even if it is only some kind of warning in the documentation...)
Regards,
--Craeg
PS I am CC-ing the zope-dev mailing list, as I think this warrants a wider audience
Jonagustine Lim wrote:
Hi!
I just noticed that it's possible to create or replace any files in the filesystem using the ZMI with ExternalFile installed.
Possible exploits:
1. Use ExternalFile web interface to replace Zope Data.fs
2. Create a .py file in /Zope/Extensions and run it by creating an Extenal Method.
Anyway, I hope you can fix this or put a warning up.
Jon
===== ------------------------------------------ JONAGUSTINE LIM Email: jonagustine_lim@yahoo.com ICQ: 2084238 ------------------------------------------ __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2