Re: [Zope-dev] localfs and zope 2.7 (was: Re: 2.7 assertion with CVS of that morning two)
Bakhtiar, thanks for your pointer. unfortunately I can not reach my-zope.org. And the cvs on sourceforge is 16 months old. Not 2.7 ready I geuess. I fixed The missing docstring problem, but I still can not add a local FS. As soon as I add a local FS to a directory, that directory becomes unaccessible. Is your LocalFS running under 2.7. What have you done? Would you min send me your adapted product ? thanks Robert On Friday 16 January 2004 10:22, Bakhtiar A Hamid wrote: On Friday 16 January 2004 17:01, [EMAIL PROTECTED] wrote: Message: 2 Date: Fri, 16 Jan 2004 00:56:36 +0100 From: robert [EMAIL PROTECTED] Subject: Re: [Zope-dev] Re: 2.7 assertion with CVS of that morning two days ago To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Thanks, Yuppie allredy pointed me to my error. Things work fine now. Strange that this is not yet fixed in the CVS. Robert The only thing I am still figthing: LocalFS does not work under 2.7. You do not happen to know how to fix it? fyi, i've danced to this tune, and the easiest is get localfs from cvs here's the document - http://www.my-zope.org/Members/kedai/News_Item.2003-12-30.2242 or sf.net/projects/localfs hth ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] post security update analysis
Now that we've reached closure on some of the outstanding security issues in Zope there's a lot of stuff in the Collector that needs to be revisited... Brian Lloyd wrote: - For loops, list comprehensions, and other iterations in untrusted code - List and dictionary instance methods in untrusted code - Use of import as in untrusted code - Use of min, max, enumerate, iter, and sum in untrusted code - Broken binding validation in untrusted code - Unpacking in untrusted code - PythonScript class security not initialized properly - PropertyManager 'lines' and 'tokens' properties stored as list - Configuration file did not override security policy selection AFAIK there weren't any public bugs related to these problems, except for maybe issue #28 which can probably be taken out of deferred status and placed into resolved now. - Unicode passed to RESPONSE.write() could shutdown process I could have sworn there was a bug report related to this but I can't find it now. - XML-RPC instance marshaling may disclose protected values issue #410, I can't comment on the effectiveness of this solution, I removed XML-RPC from my tree ages ago, I am currious if anyone has a test-case/exploit for this issue though - DTML tag dtml-tree may allow DoS attack issue #604 can be marked resolved now - Potential cross-site scripting problem in default ZSearch interface issue #734 can be marked resolved now - Proxy rights on DTMLMethods transferred via acquisition I believe this means issue #743 and issue #977 can be resolved now. Actually, #977 already was rejected IIRC but its never been marked as public which is rather irritating. - Improper security assertions on DTMLDocument objects probably fixes issue #865, but because Zope-HEAD doesn't actually run right now, due to a myriad of other bugs, I actually haven't tested it - Inadequate security assertions on admin find functions issue #1000 can be marked resolved now The patchset for 813's xss issues seems to have been partially applied. I still need to update my patch against HEAD for the xss holes that haven't been closed. I'll post an update to the collector when its ready. -- Jamie Heilman http://audible.transient.net/~jamie/ Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution. -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: 2.7 workflow not working anymore
robert wrote:
Hi there,
I have a DCWorkflow (running under plone 1.04) that has bean doing fine now for a year
or so.
Now under 2.7 I get the following traceback:
thanks for any help
Robert
Traceback (innermost last):
Module ZPublisher.Publish, line 100, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Products.CMFPlone.FormTool, line 235, in __call__
Module Products.CMFPlone.NavigationTool, line 98, in getNextObject
Module Products.CMFPlone.NavigationTool, line 289, in _getScript
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Products.CMFCore.FSPythonScript, line 92, in __call__
Module Shared.DC.Scripts.Bindings, line 261, in __call__
Module Shared.DC.Scripts.Bindings, line 292, in _bindAndExec
Module Products.CMFCore.FSPythonScript, line 126, in _exec
- __traceback_info__: ({'traverse_subpath': [], 'container': PloneSite instance at 415a00b0,
'context': Image at /intranet/intranetFHA/Members/sorg/Beispiel.jpg, 'script':
FSPythonScript at /intranet/intranetFHA/object_status_modify used for
/intranet/intranetFHA/Members/sorg/Beispiel.jpg}, ('publishCompany', '', '', '', '',
None, None, None, []), {}, (None, '', None, None, '', None, None, None, []))
Module None, line 61, in object_status_modify
Module Products.CMFPlone.WorkflowTool, line 37, in doActionFor
Module Products.CMFCore.WorkflowTool, line 309, in doActionFor
Module Products.CMFCore.WorkflowTool, line 624, in _invokeWithNotification
Module Products.DCWorkflow.DCWorkflow, line 275, in doActionFor
Module Products.DCWorkflow.DCWorkflow, line 440, in _changeStateOf
Module Products.DCWorkflow.DCWorkflow, line 489, in _executeTransition
Module Shared.DC.Scripts.Bindings, line 261, in __call__
Module Shared.DC.Scripts.Bindings, line 290, in _bindAndExec
Module Shared.DC.Scripts.Bindings, line 1, in ?
Module Shared.DC.Scripts.Bindings, line 224, in _getContext
Module AccessControl.ImplPython, line 398, in validate
Module Products.VerboseSecurity.VerboseSecurityPolicy, line 272, in validate
Unauthorized: Your user account does not have the required permission. Access to ''
of (DCWorkflowDefinition instance at 42005170) denied. Your user account, sorg, exists
at /intranet/intranetFHA/acl_users. Access requires one of the following roles:
['Manager']. Your roles in this context are ['Authenticated', 'Mitarbeiter'].
You need to update or remove VerboseSecurity (I don't think Shane has
released a 2.7 compatible version yet).
Tres.
--
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation Zope Dealers http://www.zope.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Zope 2.8?
Sorry for creating a mess, I get the error with and without VerboseSecurity. The one VerboseSecurity I am using is only a couple of days old from CVS. I thought this one was allready adapted. Robert On Saturday 17 January 2004 16:04, Jim Fulton wrote: Gfeller Martin wrote: Dear Jim, are there already plans when Zope 2.8 should see the light of the day? Other than soon, no. It depend on resources, including non-ZC contributors, and problems we encounter. I've updated the project area at: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.8 including the milestone plan: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.8/MilestonePlan We're mostly interested in the ZODB 3.3 features, i.e., getting rid of Extension Classes. Well, I hope you've been trying out the ZODB 3.3 releases and providing feedback. Jim ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CVS Head: Error Value: iterable argument required when adding objects
This error popped up in the nightly tests as well. I haven't spent any time tracking it down. On Sat, 2004-01-17 at 16:58, Jeff Kowalczyk wrote: Is anyone else seeing this with a fresh checkout of CVS head (linux, py2.3.2, 2004-01-17 16:40 EST)? When adding any object from the ZMI, I get the same error. Nothing shows up in Z2.log. I can only start zope with runzope at the moment, no error message is indicated in that console when adding. Thanks. - Site Error An error was encountered while publishing this resource. Error Type: TypeError Error Value: iterable argument required - (sidebar, the zopectl error is: $ /var/zope/bin/zopectl start Traceback (most recent call last): File /opt/Zope-2.8/lib/python/Zope/Startup/zopectl.py, line 207, in ? main() File /opt/Zope-2.8/lib/python/Zope/Startup/zopectl.py, line 190, in main c.onecmd( .join(options.args)) File /usr/lib/python2.3/cmd.py, line 210, in onecmd return func(arg) File /opt/Zope-2.8/lib/python/Zope/Startup/zopectl.py, line 134, in do_start ZDCmd.do_start(self, arg) File /opt/Zope-2.8/lib/python/zdaemon/zdctl.py, line 205, in do_start args += self._get_override(-m, umask) File /opt/Zope-2.8/lib/python/Zope/Startup/zopectl.py, line 116, in _get_override value = getattr(self.options, name) AttributeError: ZopeCtlOptions instance has no attribute 'umask' ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: CVS Head: Error Value: iterable argument required when adding objects
I forgot to check event.log, that gives information about the problem. Thanks. 2004-01-17T17:07:23 PROBLEM(100) ZODB FS FS21 warn: Ignoring index for /var/zope/var/Data.fs -- 2004-01-17T17:07:24 INFO(0) Zope Ready to handle requests -- 2004-01-17T17:07:48 PROBLEM(100) Zope Security Policy 'PermissionRole object at 0x40940db8' passed as roles during validation of 'manage_access' is not a sequence. -- 2004-01-17T17:07:48 PROBLEM(100) Zope Security Policy 'PermissionRole object at 0x40940db8' passed as roles during validation of 'manage_access' is not a sequence. -- 2004-01-17T17:08:04 PROBLEM(100) Zope Security Policy 'PermissionRole object at 0x40e4cec0' passed as roles during validation of 'manage_addFolder' is not a sequence. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CVS Head: Error Value: iterable argument required when adding objects
Jeremy Hylton wrote: I committed a patch with the umask option a few days ago. I thought it only affected zdaemon and the tests all looked clean afterwards. I'm not sure how zopectl.py ends up being affected or why there aren't any tests of it. The various scripts to start and stop programs are usually hard to test, but they're usually the source of a lot of bugs, too. Speaking as a sysadmin I'd like to suggest that the zope daemons make no efforts to frob thier assigned umasks in any way. Thats generally something the sysadmin will take care of during the startup scripts, and to have daemons change it after the fact because they think they know better causes no end of frustration. -- Jamie Heilman http://audible.transient.net/~jamie/ ...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity... -Rimmer ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CVS Head: Error Value: iterable argument required when adding objects
On Sat, 2004-01-17 at 17:22, Jamie Heilman wrote: Jeremy Hylton wrote: I committed a patch with the umask option a few days ago. I thought it only affected zdaemon and the tests all looked clean afterwards. I'm not sure how zopectl.py ends up being affected or why there aren't any tests of it. The various scripts to start and stop programs are usually hard to test, but they're usually the source of a lot of bugs, too. Speaking as a sysadmin I'd like to suggest that the zope daemons make no efforts to frob thier assigned umasks in any way. Thats generally something the sysadmin will take care of during the startup scripts, and to have daemons change it after the fact because they think they know better causes no end of frustration. You should take it up with the sysadmin on the zodb-dev list who wanted this feature :-). Daemons don't set the umask by themselves; they only do it when a sysadmin configures zdaemon to run with the --umask argument. All the advice I can find about writing daemon code suggests that setting the umask is desirable. The zdaemon code that we've been using is based on these guidelines http://www.hawklord.uklinux.net/system/daemons/d3.htm, which recommend resetting the umask in a daemon. They are basically the same as the coding rules for daemons in Steve's Advanced Programming in the Unix Environment. Jeremy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Help with the change of URL and/or port
Fábio Bruno wrote: Dear Sir or Madame I'm wrigting because I started to do a plone site in zope.I would lke to know if I can change the url and/or port where the plone site stays.I would like to know how to chenge this path http:\\localhost:8080\Plone. You need a VirtualHostMonster and possibly Apache. See the relevant chapter in the Zope Book for details, or search zope.org for VHM. --jcc ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: CVS: Releases/Zope/lib/python/ZEO - simul.py:1.12.8.2.18.18
Jeremy Hylton wrote at 2004-1-16 16:53 -0500: ... The branch tag is used for making releases for both ZODB and Zope releases. We decided to use the same branch so that we didn't have to port bug fixes to so many different branches. One downside of that merge, which we didn't realized until after it was done, is that you now get a ZEO directory in a Zope checkout on the 2.6 branch. I think there was email about the discovery at the time I found this out and was very happy... That said, I would be (a bit) unhappy when the branch information were lost for ZEO. My CVS working directory (which now contains Zope and ZEO from the 2.7 branch) would probably have some difficulties to update after the branch information is lost. It would not be a big problem, though, if I learn that it happened... -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Security audit introduced problem in PageTemplates/Expression.py
Jim Fulton wrote at 2004-1-16 18:54 -0500: ... For security checks, the accessed object should be the driving factor and not the particular way the access is made. Well, sorry, that's not what this is about. We are talking about what to do when accessing objects without roles. The ability to take the name into account is a feature that only makes sense for named, ie attribute access, imo. item is a blurred term in Python: As you know, it refers both to sequences (indexed via integers) and mappings (indexed via something hashable; often a string). When some mechanism checks whether access should be granted to individual items in a mapping, this mechanism will (almost surely) need to know the key used in the access -- and I do not see any reason why it should not be informed about the key. I do not argue that the handler registered with setDefaultAccess should be used for __getitem__ access checking. However, when it is called (as it seems to be the case), then it should be called consistently and provide as much information as useful -- this includes information about both arguments to the __getitem__ method. Even more essential for security related issues: A precise description when what security related functions are called with what arguments. The current state in this respect is far from optimal. Special points of my concern: * I never saw a description of the difference between the accessed and container parameters to validate. * I never saw a description for the three way outcome of validate: 0, 1 and raise Unauthorized. Why in hell is unauthorized encoded sometimes as return 0 and sometimes as raise Unauthorited. Looking at the code, I see that accessed/container has to do with this destinction. However, as accessed/container is unspecified, this does not clarify much. When we do not get this consistent, we open new hidden security holes (as one must always think: can this same object be accessed also in a different way and how have I to secure this way). Certainly, you have to think about how you provide access to data. Lots of data we provide access to has no security assertions of it's own. Maybe, we should change this for Zope 3? It would have been possible for Zope 2 since a long time -- but tightening security has high risk to break many applicitation (as the latest security fixes demonstrated again). Think of accessor methods that return data. If data needs to be protected, you need to think about the access methods you provide. In the future, item access will work like this: You will be able to protect __setitem__ operations. Once someone can use setitem, they can access any key. The value stored with that key may have pretections of it's own, or not. That's a matter of application design. Fine! However, security related rules are important enough that they deserve thourough and prominent specification/documentation. -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CVS Head: Error Value: iterable argument required when adding objects
Jeremy Hylton wrote: You should take it up with the sysadmin on the zodb-dev list who wanted this feature :-). They already had it, they just need to learn how to take advantage of the environment they're working in. Daemons don't set the umask by themselves; they only do it when a sysadmin configures zdaemon to run with the --umask argument. Thats good. All the advice I can find about writing daemon code suggests that setting the umask is desirable. Its desirable in some circumstances, but not all. Part of the problem is people tend to blindly follow the traditional approach to daemon design without bothering to actually do any critical thinking. There are several very reasonable arguments for deviation from the historical approach. Perhaps the most relevant argument is the same old one about the Unix design philosophy; many small programs working together is more a flexible and ultimately useful approach than a monolithic one-program-does-it-all design. Anyway, if you want to question authority, consider reading: http://homepages.tesco.net/~J.deBoynePollard/FGA/unix-daemon-design-mistakes-to-avoid.html or http://cloud9.hedgee.com./scribbles/daemon or even better yet, look back over the CVS commits and bugs fixed in the Zope code (or other traditional-design daemons) that have been related to the current design choices and think about how they could have arisen under the more modular approach and how they might have been fixed in those circumstances. -- Jamie Heilman http://audible.transient.net/~jamie/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CVS Head: Error Value: iterable argument required when adding objects
On Sat, 2004-01-17 at 18:30, Jamie Heilman wrote: Its desirable in some circumstances, but not all. Part of the problem is people tend to blindly follow the traditional approach to daemon design without bothering to actually do any critical thinking. I expect you don't intend to sound rude, but this gives the impression you think I've failed to do some necessary critical thinking. Even if I you think that, it's hardly diplomatic to point it out. There are several very reasonable arguments for deviation from the historical approach. What are they? historical approach. Perhaps the most relevant argument is the same old one about the Unix design philosophy; many small programs working together is more a flexible and ultimately useful approach than a monolithic one-program-does-it-all design. I don't follow how this advice relates to the current discussion. We're talking about whether zdrun.py should have a --umask option. zdrun is a small program. It just allows some other program to run as a daemon. Anyway, if you want to question authority, consider reading: http://homepages.tesco.net/~J.deBoynePollard/FGA/unix-daemon-design-mistakes-to-avoid.html I don't see how this questions authority. It sounds entirely compatible with the design of zdaemon.(The TCP/IP stuff doesn't apply to zdaemon, and Zope works differently, but that's typical for app servers.) Are you familiar with zdaemon? Jeremy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CVS Head: Error Value: iterable argument required when adding objects
Jeremy Hylton wrote: On Sat, 2004-01-17 at 18:30, Jamie Heilman wrote: Its desirable in some circumstances, but not all. Part of the problem is people tend to blindly follow the traditional approach to daemon design without bothering to actually do any critical thinking. I expect you don't intend to sound rude, but this gives the impression you think I've failed to do some necessary critical thinking. Even if I you think that, it's hardly diplomatic to point it out. No I don't think you failed in any way, sorry if I gave that impression. I intended to bemoan the overall state of what are generally espoused to be best-practices when it comes to daemon design. As you said, the umask code only comes into play when explicitly asked for, and I think thats a really good thing, my initial concern was that the umask would be set to a default value regardless of the parent process's properties. There are several very reasonable arguments for deviation from the historical approach. What are they? They were listed in the URIs, but the jist is that its better to let small dedicated programs handle the daemonization and supervision of long-running code, than it is to embed those gymnastics into the code itself. I don't follow how this advice relates to the current discussion. We're talking about whether zdrun.py should have a --umask option. Ah, well, you are maybe--to me I see an error thats carping about a missing umask attribute value and no mention of zdrun, so it wasn't immediately clear to me which aspects of zope the umask would apply to. Now that I know its part of a broad (entire process group) control mechanism I'm less concerned. Anyway, if you want to question authority, consider reading: http://homepages.tesco.net/~J.deBoynePollard/FGA/unix-daemon-design-mistakes-to-avoid.html I don't see how this questions authority. It sounds entirely compatible with the design of zdaemon. Well, yes, to an extent. There's a large breakdown when it comes to the design of event logging. (The TCP/IP stuff doesn't apply to zdaemon, and Zope works differently, but that's typical for app servers.) agreed Are you familiar with zdaemon? In purpose yes, but I don't use it in production. -- Jamie Heilman http://audible.transient.net/~jamie/ Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution. -Sathington Willoughby ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
