[Zope] Modification Posts to the list (was: [Zope] Import from file via management-interface)
Hi Tino (and other potential patch posters), if possibly, you should not post complete source modules to the list. Instead, you should use either context or uniform differences to the source. Such a difference file is called a patch. Patches have considerable advantages over the complete source: * they are much smaller * they can (usually) be applied to more than one version * they show directly what has been changed, this is essential for a decision whether or not to trust the changes. I will never install any source modules posted to the list. Usually, I will not even look at them. Patches can be created with the "diff" utility. This is a "standard" unix program (i.e. installed on any Unix system). There is an improved GNU version, which is also available for Win/32. There are other Windows implementations for "diff". Patches are applied with the "patch" utility. Again, there is a GNU version, and surely there are versions for Win/32. Dieter ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Import from file via management-interface
Hi Bill, Bill Anderson wrote: How about just the patch next time, as opposed ot the whole patched filed? Ah yes, sure. On the other hand its more convient for the windows people, without a patch at hand... regards Tino ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Import from file via management-interface
Hi Terry, Terry Kerr wrote: you can write anything destructive, whether it is an external method, a DTML Method, or basically anything. At least if the only way you can import .zexp's is from the import directory, then only people with access to the zope file structure can import stuff...that will usually be restricted to system administrators or superuser people. Hm. I dont see the point here. First you can restrict the ability to Export/Import in the users role. Second, the either the superuser has to be bothered with imports or you have to grant all the people access to the file system. This would be much lesser security as beeing able to import via web. May be I schould have a deeper look at the ownership-problem. Giving the importing user ownership over all objects (s)he imports as long it is not the superuser, schould do the trick. Regards Tino ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Import from file via management-interface
On Sat, Sep 09, 2000 at 09:39:33AM +0200, Tino Wildenhain wrote: Terry Kerr wrote: you can write anything destructive, whether it is an external method, a DTML Method, or basically anything. At least if the only way you can import .zexp's is from the import directory, then only people with access to the zope file structure can import stuff...that will usually be restricted to system administrators or superuser people. Hm. I dont see the point here. First you can restrict the ability to Export/Import in the users role. Second, the either the superuser has to be bothered with imports or you have to grant all the people access to the file system. This would be much lesser security as beeing able to import via web. May be I schould have a deeper look at the ownership-problem. Giving the importing user ownership over all objects (s)he imports as long it is not the superuser, schould do the trick. The problem is not so much ownership of the objects imported, but the type of objects that can be instanciated from a pickle (the export format wether XML or binary, consists of pickled classes). You can create _everything_ from a pickle, as long as there is a class definition for it; including a monitor client. I can open up a high port on your machine that'll let me connect to your Zope process in a python interpreter prompt. Then your server is my oister. Allowing imports from arbitrary paths will let me exploit security holes in other internet daemons on your machine to create a pickle file for import; preferably the /tmp directory as it is world writeable. Restricting imports to one directory allows you to be much more restrictive as to who can write there. You can set up restricted FTP access or even only allow scp (ssh encrypted file transfer) for trusted people to upload exports to the Zope import directory if you need to give others import rights. -- Martijn Pieters | Software Engineermailto:[EMAIL PROTECTED] | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ | ZopeStudio: http://www.zope.org/Products/ZopeStudio - ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Import from file via management-interface
Hi, Martijn Pieters wrote: On Sat, Sep 09, 2000 at 09:39:33AM +0200, Tino Wildenhain wrote: Terry Kerr wrote: you can write anything destructive, whether it is an external method, a DTML Method, or basically anything. At least if the only way you can import .zexp's is from the import directory, then only people with access to the zope file structure can import stuff...that will usually be restricted to system administrators or superuser people. Hm. I dont see the point here. First you can restrict the ability to Export/Import in the users role. Second, the either the superuser has to be bothered with imports or you have to grant all the people access to the file system. This would be much lesser security as beeing able to import via web. May be I schould have a deeper look at the ownership-problem. Giving the importing user ownership over all objects (s)he imports as long it is not the superuser, schould do the trick. The problem is not so much ownership of the objects imported, but the type of objects that can be instanciated from a pickle (the export format wether XML or binary, consists of pickled classes). You can create _everything_ from a pickle, as long as there is a class definition for it; including a monitor client. I can open up a high port on your machine that'll let me connect to your Zope process in a python interpreter prompt. Then your server is my oister. Thats badly true, but importing of a whole bunch of objects is also often needed. IIRC does pickle only handle instance data but not class code. (although I see using of marshal in the import code which does in fact import code as oposite to pickle) Importing instance data schould not be a problem since it can only work if the user in question has access to the classes. This access is already handled by permissions. Moreover we could restrict importing via web to the superuser at all. Allowing imports from arbitrary paths will let me exploit security holes in other internet daemons on your machine to create a pickle file for import; preferably the /tmp directory as it is world writeable. Restricting imports to one directory allows you to be much more restrictive as to who can write there. You can set up restricted FTP access or even only allow scp (ssh encrypted file transfer) for trusted people to upload exports to the Zope import directory if you need to give others import rights. Uh, do you know any ssh-daemon for windows? ;-) Regards ;-) Tino ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Import from file via management-interface
On Sat, Sep 09, 2000 at 03:54:25PM +0200, Tino Wildenhain wrote: The problem is not so much ownership of the objects imported, but the type of objects that can be instanciated from a pickle (the export format wether XML or binary, consists of pickled classes). You can create _everything_ from a pickle, as long as there is a class definition for it; including a monitor client. I can open up a high port on your machine that'll let me connect to your Zope process in a python interpreter prompt. Then your server is my oister. Thats badly true, but importing of a whole bunch of objects is also often needed. IIRC does pickle only handle instance data but not class code. (although I see using of marshal in the import code which does in fact import code as oposite to pickle) Importing instance data schould not be a problem since it can only work if the user in question has access to the classes. This access is already handled by permissions. No it isn't. Web access to class instances is handled by permissions. Unpickling will cause class instantiation in the python process, where you have no control over what get's created. You can create a custom unpickling class, but one that would handle the Zope range of objects would be, in Jim's words "tricky". Moreover we could restrict importing via web to the superuser at all. This would completely defeat your idea that people besides the superuser should be able to import. Apart from being a security risk. Allowing imports from arbitrary paths will let me exploit security holes in other internet daemons on your machine to create a pickle file for import; preferably the /tmp directory as it is world writeable. Restricting imports to one directory allows you to be much more restrictive as to who can write there. You can set up restricted FTP access or even only allow scp (ssh encrypted file transfer) for trusted people to upload exports to the Zope import directory if you need to give others import rights. Uh, do you know any ssh-daemon for windows? ;-) Sorry, no, but that's because I never looked. I am sure there are other secure options for file transfer for Win32 available though. -- Martijn Pieters | Software Engineermailto:[EMAIL PROTECTED] | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ | ZopeStudio: http://www.zope.org/Products/ZopeStudio - ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
RE: [Zope] Import from file via management-interface
you can write anything destructive, whether it is an external method, a DTML Method, or basically anything. At least if the only way you can import .zexp's is from the import directory, then only people with access to the zope file structure can import stuff...that will usually be restricted to system administrators or superuser people. But if there was a Can Import From Web role than you could control who could import and who couldn't. Granular Security is a strong point of Zope. We should strive to use it. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[Zope] Import from file via management-interface
Hi all,
I found it very disturbing having to get my .zexp exports
into the subdirectory 'import' of the server and then using
the management-interface to do the actual import.
So I patched ObjectManager and the compaining dtml-file.
Please check them out (included in the mail, sorry for the
traffic) if I should post them to the collector.
Regards
Tino
##
#
# Zope Public License (ZPL) Version 1.0
# -
#
# Copyright (c) Digital Creations. All rights reserved.
#
# This license has been certified as Open Source(tm).
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are
# met:
#
# 1. Redistributions in source code must retain the above copyright
#notice, this list of conditions, and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions, and the following disclaimer in
#the documentation and/or other materials provided with the
#distribution.
#
# 3. Digital Creations requests that attribution be given to Zope
#in any manner possible. Zope includes a "Powered by Zope"
#button that is installed by default. While it is not a license
#violation to remove this button, it is requested that the
#attribution remain. A significant investment has been put
#into Zope, and this effort will continue if the Zope community
#continues to grow. This is one way to assure that growth.
#
# 4. All advertising materials and documentation mentioning
#features derived from or use of this software must display
#the following acknowledgement:
#
# "This product includes software developed by Digital Creations
# for use in the Z Object Publishing Environment
# (http://www.zope.org/)."
#
#In the event that the product being advertised includes an
#intact Zope distribution (with copyright and license included)
#then this clause is waived.
#
# 5. Names associated with Zope or Digital Creations must not be used to
#endorse or promote products derived from this software without
#prior written permission from Digital Creations.
#
# 6. Modified redistributions of any form whatsoever must retain
#the following acknowledgment:
#
# "This product includes software developed by Digital Creations
# for use in the Z Object Publishing Environment
# (http://www.zope.org/)."
#
#Intact (re-)distributions of any official Zope release do not
#require an external acknowledgement.
#
# 7. Modifications are encouraged but must be packaged separately as
#patches to official Zope releases. Distributions that do not
#clearly separate the patches from the original work must be clearly
#labeled as unofficial distributions. Modifications which do not
#carry the name Zope may be packaged in any form, as long as they
#conform to all of the clauses above.
#
#
# Disclaimer
#
# THIS SOFTWARE IS PROVIDED BY DIGITAL CREATIONS ``AS IS'' AND ANY
# EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
# PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL DIGITAL CREATIONS OR ITS
# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
# USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
# ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
# OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
# OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
#
#
# This software consists of contributions made by Digital Creations and
# many individuals on behalf of Digital Creations. Specific
# attributions are listed in the accompanying credits file.
#
##
__doc__="""Object Manager
$Id: ObjectManager.py,v 1.98.8.7 2000/08/17 20:20:01 shane Exp $"""
__version__='$Revision: 1.98.8.7 $'[11:-2]
import App.Management, Acquisition, Globals, CopySupport, Products
import os, App.FactoryDispatcher, ts_regex, Products
from OFS.Traversable import Traversable
from Globals import HTMLFile, HTMLFile, Persistent
from Globals import MessageDialog, default__class_init__
from webdav.NullResource import NullResource
from webdav.Collection import Collection
from Acquisition import aq_base
from urllib import quote
from cStringIO import StringIO
import marshal
import App.Common
from AccessControl import getSecurityManager
from zLOG import LOG, ERROR
import sys
import XMLExportImport
customImporters={
XMLExportImport.magic: XMLExportImport.importXML,
}
Re: [Zope] Import from file via management-interface
How about just the patch next time, as opposed ot the whole patched filed? -- Do not meddle in the affairs of sysadmins, for they are easy to annoy, and have the root password. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Import from file via management-interface
I found it very disturbing having to get my .zexp exports into the subdirectory 'import' of the server and then using the management-interface to do the actual import. I found it inconvenient, too. (Not disturbing, though.) And I had to implement my own uploading scheme via web. But as anything that is put into the file system, I thought that there must be some security reason. At least I know that's why the Extensions folder is there. Is this (existence of import folder) really a shortcoming of Zope, or is there some security reason why .zexp cannot be uploaded directly from browser? Can someone somehow write a destructive external method, and then upload it via .zexp? regards, Hung Jung _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Import from file via management-interface
you can write anything destructive, whether it is an external method, a DTML Method, or basically anything. At least if the only way you can import .zexp's is from the import directory, then only people with access to the zope file structure can import stuff...that will usually be restricted to system administrators or superuser people. terry Hung Jung Lu wrote: I found it very disturbing having to get my .zexp exports into the subdirectory 'import' of the server and then using the management-interface to do the actual import. I found it inconvenient, too. (Not disturbing, though.) And I had to implement my own uploading scheme via web. But as anything that is put into the file system, I thought that there must be some security reason. At least I know that's why the Extensions folder is there. Is this (existence of import folder) really a shortcoming of Zope, or is there some security reason why .zexp cannot be uploaded directly from browser? Can someone somehow write a destructive external method, and then upload it via .zexp? regards, Hung Jung _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev ) -- Terry Kerr ([EMAIL PROTECTED]) Adroit Internet Solutions Pty Ltd (www.adroit.net) Phone: +613 9563 4461 Fax: +613 9563 3856 Mobile: +61 414 708 124 ICQ: 79303381 ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
