Re: [Zope-dev] Re: Security audit introduced problem in PageTemplates/Expression.py
Dieter Maurer wrote: Jim Fulton wrote at 2004-1-15 17:23 -0500: BTW, telling me that an algorithm has changed doesn't constitute a use case. :) I know that algorithm has changed. I assert that we don't need the feature that the change broke. I am open to evidence to the contrary. Do you have a convincing reason to change the behaviour? I argue here with consistency: When the "setDefaultAccess" function is called, it should always be called with sensible (and consistent) arguments. In my view, it is not consistent, that the function is called with the attribute name when the attribute is accessed via "attribute access syntax" but called with "None" when the same attribute it accessed via "item access syntax". Huh? Nobody's calling setDefaultAccess with None. Stuart is calling it with a handler function. AFAICT, the use of a handler fucntion is undocumented. It should be documented, but with different semantics than Stuart expects. :) 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. 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. 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. However, for backward compataibility, we'll leave things the way they were, at least until Zope 2.9. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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: Stuart Bishop wrote: ... It was never intended that the ability to control unprotected sub-objects by name would apply to items. It was sloppy coding on my part that item indexes (yes, indexes, like, say, 1) and keys were passed as names. I can certainly understand why people looking at the code and trying things out would come to the wrong conclusion. But it would depend on which code they looked at. For example, in 2.6.2, the key is not passed to validate when traversing using getitem in unrestrictedTraverse. For this reason, it's brittle to rely on this, even without the recent security changes. Fundamentally, it's wrong to use the same mechanism for attributes and item keys or indexes. In the recent security work, we tried to address this by not passing the name for for item access. Unfortunately, this broke some code. I *think* that there cannot be too many cases of this. I I'm pretty sure that I can redo the way we protect dictionaries and lists so that we can provide backward compatability. If I can do this, I will, because backward compatability *is* important, especially for bug-fix releases. This is done and checked into the Zope 2.7 branch (Zope-2_7-branch). Stuart, can you try this out and make sure that your application works as it did before? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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] 2.7 management_page_charset cannot be callable anymore
Hi >Hi guys - > >I was trying to be responsive to getting the issue resolved, since >I'd like to make a (hopefully final) beta of 2.7 of Friday. I'll be >happy to check in (or have you check in) whatever fixes are needed >to give you the flexibility you need so long as it is b/w compatible, >but I won't have the time to actively figure out what those fixes >are this week. > >If you or Hajime can send me a patch against the current 2.7 >branch, I'll make sure they get in before the beta is cut (or if >either of you are committers it is also fine to checkin yourselves >to the Zope-2_7-branch and head and let me know when its done). > I have checkout 2.7 branch and test. And now seems good works for me. http://cvs.zope.org/Zope/lib/python/OFS/dtml/properties.dtml.diff?r1=1.8.18.6&r2=1.8.18.7 Thanks a lot Brian. Is it good for you, Martijn ? Regards, Hajime Nakagami ___ 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: Releases/Zope/lib/python/ZEO - simul.py:1.12.8.2.18.18
Paul Winkler wrote: On Fri, Jan 16, 2004 at 04:53:02PM -0500, Jeremy Hylton wrote: 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. downside??? I thought that was a good thing! I think there was email about the discovery at the time, and I noticed that Brian did not include ZEO in the 2.6.3 releases; so I assume he's got some mechanism to suppress it from the actual release. Consider this a request to disable that mechanism ;-) ZEO was a (big) new feature in the 2.7 line; propagating it into 2.6 violates our stated release engineering policies, by a *lot* (likewise BDBStorage). 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: CVS: Releases/Zope/lib/python/ZEO - simul.py:1.12.8.2.18.18
On Fri, Jan 16, 2004 at 04:53:02PM -0500, Jeremy Hylton wrote: > 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. downside??? I thought that was a good thing! > I think there was email about the discovery at the time, and I > noticed that Brian did not include ZEO in the 2.6.3 releases; so I > assume he's got some mechanism to suppress it from the actual release. Consider this a request to disable that mechanism ;-) -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's SUPER FRED! (random hero from isometric.spaceninja.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: CVS: Releases/Zope/lib/python/ZEO - simul.py:1.12.8.2.18.18
On Fri, 2004-01-16 at 13:58, Tres Seaver wrote: > This is a result of some funny repository fiddling, which somehow got > both 'ZEO' and 'BDBStorage' onto the 'Zope-2_6-branch'. I would like to > remove the branch tag altogether, as neither module is part of the 2.6 > release. 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, and I noticed that Brian did not include ZEO in the 2.6.3 releases; so I assume he's got some mechanism to suppress it from the actual release. I'd write this down somewhere more permanent if anyone can suggest a good place. 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 )
[Zope-dev] Re: CVS: Releases/Zope/lib/python/ZEO - simul.py:1.12.8.2.18.18
Evan Simpson wrote: Update of /cvs-repository/Releases/Zope/lib/python/ZEO In directory cvs.zope.org:/tmp/cvs-serv18593/lib/python/ZEO Modified Files: Tag: Zope-2_6-branch simul.py Log Message: Non-Python 2.1-compatible division operator "//" crept into 2.6 branch. This is a result of some funny repository fiddling, which somehow got both 'ZEO' and 'BDBStorage' onto the 'Zope-2_6-branch'. I would like to remove the branch tag altogether, as neither module is part of the 2.6 release. Here is what I would propose doing:: $ ssh cvs.zope.org $ cd /cvs-repository $ tar czf /tmp/Zope-just_in_case.tar.gz Zope $ ^D $ cvs -d :ext:cvs.zope.org:/cvs-repository \ rtag -dB Zope-2_6-branch Zope/lib/python/ZEO $ cvs -d :ext:cvs.zope.org:/cvs-repository \ rtag -dB Zope-2_6-branch Zope/lib/python/BDBStorage Anybody know a reason why we shouldn't do this? The CVS docs seem to consider deleting branch tags a Bad Thing (TM), but I have never seen any rationale for it. 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] win32 setup sources
On Fri, 2004-01-16 at 13:15, Brian Lloyd wrote: > For 2.7.0 and above, we've moved to using InnoSetup. We haven't > worked out the best way to move that work to the public cvs yet. > If you're planning to bundle 2.7, let me know and I can at least > get you a snapshot of the install materials. It's already in Zope.org CVS as Packages/WinBuilders. - C ___ 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] win32 setup sources
> I need a solution to quickly and easily deploy zope applications > on the win32 > platform. What I'd like to realize is a setup program that install and > configure Zope bundled with all the needed products, making > questions to the > user for correctly setup the application. Unfortunately I have no > experiences > in windows programming and related setup tools and I'm lookin for good > examples. Can someone tell me something about the win32 Zope > installer and > the tool used to build the executable? Are the sources available so I can > simply customize them? (this is why I've sent the post to this > list, please > sorry if I'm OT!!) For versions of Zope up to and including 2.6.x, we've been using the WISE installer (5.0 I think). You can find the WISE setup script (zope2.wse) in the 'inst' directory of a Zope install on windows. For 2.7.0 and above, we've moved to using InnoSetup. We haven't worked out the best way to move that work to the public cvs yet. If you're planning to bundle 2.7, let me know and I can at least get you a snapshot of the install materials. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation 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 )
[Zope-dev] win32 setup sources
Hi, I need a solution to quickly and easily deploy zope applications on the win32 platform. What I'd like to realize is a setup program that install and configure Zope bundled with all the needed products, making questions to the user for correctly setup the application. Unfortunately I have no experiences in windows programming and related setup tools and I'm lookin for good examples. Can someone tell me something about the win32 Zope installer and the tool used to build the executable? Are the sources available so I can simply customize them? (this is why I've sent the post to this list, please sorry if I'm OT!!) Thanx A. ___ 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] [ZConfig] elementary function framework and "env" function
We often have the need to use the same configuration value both in a ZConfig configuration as well as in other non-ZConfig based "components". Prominent examples are the "INSTANCE_HOME" in the Zope/ZEO startup scripts and the "INSTANCE" definition in the corresponding configuration files. Moreover, configuration values are sometimes arithmethically related, but ZConfig lacks arithmetic capabilities. An example is the ZEO port which should (under some conditions) be derived from "PORT_BASE". Giving "ZConfig" access to the environment, allows configuration setup to use the arithmetic capabilities of the shell and communicate configuation values via the environment between "ZConfig" based components and components that use different configuration schemes. The attached patch gives "ZConfig" an elementary function framework. An application can register functions with "ZConfig". These functions can be called through "substitution". Its syntax is similar to "gmakes" function call: $(f) calls function "f" with no arguments $(f a1,a2,...) calls function "f" with arguments "a1", "a2", ... Arguments are "," separated, stripped and substitution expanded before they are passed to the function. "," can be escaped through duplication, "(" is not allowed in the "ai" (although they can come up after substitution). Functions are called with "mapping" as additional first argument (such that they can do fancy things; e.g. implement Bash's "default" interpolation ("${name:-default}"). The patch uses the framework to implement a single function "env": env(name, default=None) returns the value of "name" in the environment or "default". If the result it "None", a "KeyError" is raised. -- Dieter --- :functions.py 1970-01-01 01:00:00.0 +0100 +++ functions.py 2004-01-16 16:02:01.0 +0100 @@ -0,0 +1,53 @@ +# $Id: functions.py,v 1.1 2004/01/16 15:02:01 dieter Exp $ + +"""Substitution function support for ZConfig values. + +Functions are called with an additional (first) mapping argument. +It contains the currently known definitions. +""" + +# registry +class Registry: +'''a function registry.''' + +def __init__(self): +self._functions = {} + +def _normalize(self, name): +return name.lower() # ZConfig seems to strive for case insensitiveness + +def register(self, name, function, overwrite=False): +'''register *function* under *name*.''' +name = self._normalize(name) +known = self._functions +if not overwrite: +# check, we do not yet know this function +f = known.get(name) +if f is not None and f != function: +raise ValueError("function '%s' already registered" % name) +known[name] = function + +def resolve(self, name): +'''return function registered for *name* or 'None'.''' +name = self._normalize(name) +return self._functions.get(name) + +_registry = Registry() + +registerFunction = _registry.register +resolveFunction = _registry.resolve + +def _env(mapping, name, default=None): +'''look up *name* in environment. + +return *default* if unsuccessful; +raise 'KeyError' if *default is 'None' +''' +from os import environ +v = environ.get(name, default) +if v is not None: return v +raise KeyError("environment does not define name", name) + +registerFunction('env', _env) + + --- :substitution.py 2003-12-22 07:27:36.0 +0100 +++ substitution.py 2004-01-16 13:38:07.0 +0100 @@ -15,6 +15,8 @@ import ZConfig +from functions import resolveFunction + try: True except NameError: @@ -31,9 +33,12 @@ p, name, namecase, rest = _split(rest) result += p if name: -v = mapping.get(name) -if v is None: -raise ZConfig.SubstitutionReplacementError(s, namecase) +if isinstance(name, _Function): +v, rest = name(mapping) +else: +v = mapping.get(name) +if v is None: +raise ZConfig.SubstitutionReplacementError(s, namecase) result += v return result else: @@ -75,6 +80,14 @@ if not s.startswith("}", i - 1): raise ZConfig.SubstitutionSyntaxError( "'${%s' not followed by '}'" % name) +elif c == "(": +m = _name_match(s, i + 2) +if not m: +raise ZConfig.SubstitutionSyntaxError( +"'$(' not followed by name") +name = m.group(0) +i = m.end() + 1 +return prefix, _Function(s, m), None, None else: m = _name_match(s, i+1) if not m: @@ -90,3 +103,62 @@ import re _name_match = re.compile(r"[a-zA-Z_][a-zA-Z0-9_]*").match del re + +class _Function: +'''encaps
[Zope-dev] [ZConfig] "redefine" extension
It is often favorable to have a set of site wide defines that can occasionally be redefined for special purposes. The attached patch adds a "%redefine" directive to ZConfig's "cfgparser". "%redefine" behaves exactly like "define" but does not check whether the name is already defined. -- Dieter --- :cfgparser.py 2003-12-22 07:27:36.0 +0100 +++ cfgparser.py 2004-01-16 15:41:40.0 +0100 @@ -138,7 +138,7 @@ if not m: self.error("missing or unrecognized directive") name, arg = m.group('key', 'value') -if name not in ("define", "import", "include"): +if name not in ("define", "import", "include", "redefine"): self.error("unknown directive: " + `name`) if not arg: self.error("missing argument to %%%s directive" % name) @@ -146,6 +146,8 @@ self.handle_include(section, arg) elif name == "define": self.handle_define(section, arg) +elif name == "redefine": +self.handle_define(section, arg, False) elif name == "import": self.handle_import(section, arg) else: @@ -160,13 +162,13 @@ newurl = ZConfig.url.urljoin(self.url, rest) self.context.includeConfiguration(section, newurl, self.defs) -def handle_define(self, section, rest): +def handle_define(self, section, rest, preventOverride=True): parts = rest.split(None, 1) defname = parts[0].lower() defvalue = '' if len(parts) == 2: defvalue = parts[1] -if self.defs.has_key(defname): +if preventOverride and self.defs.has_key(defname): self.error("cannot redefine " + `defname`) if not isname(defname): self.error("not a substitution legal name: " + `defname`) ___ 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: Zope-2.6.3 issue with CMF-1.3.3 portal_types
Erik A.Dahl wrote: I downloaded 2.6.3 to do some testing and found that with a totally generic CMF-1.3.3 there is an issue with opening properties of a portal type. Here is the stack trace: Traceback (innermost last): Module ZPublisher.Publish, line 98, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module Products.CMFCore.utils, line 313, in manage_propertiesForm Module Shared.DC.Scripts.Bindings, line 261, in __call__ Module Shared.DC.Scripts.Bindings, line 292, in _bindAndExec Module App.special_dtml, line 174, in _exec Module DocumentTemplate.DT_In, line 703, in renderwob Module DocumentTemplate.DT_Let, line 76, in render Module DocumentTemplate.DT_Util, line 201, in eval - __traceback_info__: select_variable Module , line 0, in ? AttributeError: min I walked back up this stack but I can't say I quite get it. Any body else? Error is provoked just by licking on one of the type objects in portal_types of a newly created totally generic portal. Collector #1169: http://zope.org/Collectors/Zope/1169 Fixed in CVS for 2.6 branch, 2.7 branch, and HEAD; this fix will be in the upcoming 2.6.4b1 release. 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 )
[Zope-dev] Zope-2.6.3 issue with CMF-1.3.3 portal_types
I downloaded 2.6.3 to do some testing and found that with a totally generic CMF-1.3.3 there is an issue with opening properties of a portal type. Here is the stack trace: Traceback (innermost last): Module ZPublisher.Publish, line 98, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module Products.CMFCore.utils, line 313, in manage_propertiesForm Module Shared.DC.Scripts.Bindings, line 261, in __call__ Module Shared.DC.Scripts.Bindings, line 292, in _bindAndExec Module App.special_dtml, line 174, in _exec Module DocumentTemplate.DT_In, line 703, in renderwob Module DocumentTemplate.DT_Let, line 76, in render Module DocumentTemplate.DT_Util, line 201, in eval - __traceback_info__: select_variable Module , line 0, in ? AttributeError: min I walked back up this stack but I can't say I quite get it. Any body else? Error is provoked just by licking on one of the type objects in portal_types of a newly created totally generic portal. -EAD ___ 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
Stuart Bishop wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16/01/2004, at 9:23 AM, Jim Fulton wrote: Dieter Maurer wrote: Jim Fulton wrote at 2004-1-15 10:03 -0500: ... Right. The name attribute was intended for attribute-based access. IMO, it makes no sense to consider key values when doing security checks. I had thought we had more, More what? but most of that logic is now in a ComputedAttribute __ac_local_roles__ and in our __getitem__ hooks. What we currently have is a BTree storing key -> value. Valid keys are defined by a schema. If that schema changes, we do not want to lose the information until we are sure it has been archived, but we no longer want it available. The sorts of things we *were* doing was allowing access to certain attributes I'm confused. Attributes of what? Above you are refering to a BTree. if the currently authenticated user had required permissions on a related object. eg. A bag-of-metadata has an associated Publisher object, and the Publisher has Editors (implemented as a local role assigned in the Publisher). Access to bits of metadata would be calculated based on the bag's schema, which determined if each bit was private, public or shared. Shared was available to people with certain permissions on the bag, or to people with certain permissions on the associated Publisher (the Editors). Some metadata has calculated privacy settings (eg. EmailAddress is shared or public depending on the value of PrivateEmailAddress) We now have the situation that this is possible if bag-of-metadata is accessed via getattr (stored as attributes on the object), but not via getitem (stored anywhere else). My suggestion would be to wrap the BTree in an object that accesses it via getattr. I can also imagine BTrees keyed to userid (eg storing settings), where people can only access their branch or branches of people in their workgroup. Sure, but, presumably, these settings would be objects that would have p[rotections defined for their attributes. BTW, telling me that an algorithm has changed doesn't constitute a use case. :) I know that algorithm has changed. I assert that we don't need the feature that the change broke. I am open to evidence to the contrary. Its probably a feature we don't *need*, but some of us happen to be using it, and have been using this documented feature since Zope 2.5. Where is it documented? I did a quick look, and couldn'd find documentation of this feature. I can probably work around it (although it means the next milestone release next week will be on b3 instead of b4), but I'd assumed that if one person who is using the beta triggered this issue, there will be plenty more who may be upset when they try porting their apps to 2.7.0 release. Treating item access and attribute access the same way has some inherent problems. We ran into this in the security work. We needed to provide protection for some methods on lists and dictionaries. when we implemented this, we found we could no-longer access their items. It was never intended that the ability to control unprotected sub-objects by name would apply to items. It was sloppy coding on my part that item indexes (yes, indexes, like, say, 1) and keys were passed as names. I can certainly understand why people looking at the code and trying things out would come to the wrong conclusion. Fundamentally, it's wrong to use the same mechanism for attributes and item keys or indexes. In the recent security work, we tried to address this by not passing the name for for item access. Unfortunately, this broke some code. I *think* that there cannot be too many cases of this. I I'm pretty sure that I can redo the way we protect dictionaries and lists so that we can provide backward compatability. If I can do this, I will, because backward compatability *is* important, especially for bug-fix releases. I'll say, however that this "feature" should be considered deprecated. We will *not* allow you to control access based on item keys or indexes in Zope 3. I *hope* to merge the Zope 2 and Zope 3 protection schemes in Zope 2.9, so you should expect this feature to go away in Zope 2.9. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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
Dieter Maurer wrote: Jim Fulton wrote at 2004-1-15 17:23 -0500: ... None should never be passed for attribute accesses. If it is, then there is a bug. The case of dictionary mapping names to whatever is for attribute access. We are talking about item/key access. I haven't seen a use case for needing to specify separate access for separate key values. The original problem report (at least the one I read in this mailing list) was that a function registered with "setDefaultAccess" was called with "None" as "name" argument. I expect that such a function is not called for dictionary or list access but only for access to (class) instances. When it is called, the name is relevant, as usually the name will be used to distinquish which attributes should be accessible and which not. Well, the proginal message in this thread refers to an item access. *** *** 312,318 # Skip directly to item access o = object[name] # Check access to the item. ! if not validate(object, object, name, o): raise Unauthorized, name object = o continue The code above this: if not name or name[0] == '_': Checks for empty names or names beginning with underscrores, neither of which are legal attribite names. So, this does seem to be about item access. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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] localfs and zope 2.7 (was: Re: 2.7 assertion with CVS of that morning two)
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 )
Re: [Zope-dev] 2.7 management_page_charset cannot be callable anymore
As the originator of management_page_charset, I should have jumped into this thread earlier. My appologies for my late arrival. On Thursday 15 January 2004 17:22, Martijn Faassen wrote: > it assumes the only place > management_page_charset can be coming from is a property, which is > not true. Ive missed the use case that needs this. management_page_charset was added as a transition aid for people who already had sites where their use of the management interface assumed something other than latin-1 was used for plain string properties. That is, a transition towards using unicode objects for storing all natural language strings. I wouldnt like to see management_page_charset grow into something bigger than this - its too ugly. > Considering the amount of rewriting necessary to make this saner and the > scariness of doing that just before a Zope 2.7 release, I'll skip it > and live with my Formulator hack solution. Can you point me to a desicription of this hack please. -- Toby Dickenson ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16/01/2004, at 9:23 AM, Jim Fulton wrote: Dieter Maurer wrote: Jim Fulton wrote at 2004-1-15 10:03 -0500: ... Right. The name attribute was intended for attribute-based access. IMO, it makes no sense to consider key values when doing security checks. I had thought we had more, but most of that logic is now in a ComputedAttribute __ac_local_roles__ and in our __getitem__ hooks. What we currently have is a BTree storing key -> value. Valid keys are defined by a schema. If that schema changes, we do not want to lose the information until we are sure it has been archived, but we no longer want it available. The sorts of things we *were* doing was allowing access to certain attributes if the currently authenticated user had required permissions on a related object. eg. A bag-of-metadata has an associated Publisher object, and the Publisher has Editors (implemented as a local role assigned in the Publisher). Access to bits of metadata would be calculated based on the bag's schema, which determined if each bit was private, public or shared. Shared was available to people with certain permissions on the bag, or to people with certain permissions on the associated Publisher (the Editors). Some metadata has calculated privacy settings (eg. EmailAddress is shared or public depending on the value of PrivateEmailAddress) We now have the situation that this is possible if bag-of-metadata is accessed via getattr (stored as attributes on the object), but not via getitem (stored anywhere else). I can also imagine BTrees keyed to userid (eg storing settings), where people can only access their branch or branches of people in their workgroup. BTW, telling me that an algorithm has changed doesn't constitute a use case. :) I know that algorithm has changed. I assert that we don't need the feature that the change broke. I am open to evidence to the contrary. Its probably a feature we don't *need*, but some of us happen to be using it, and have been using this documented feature since Zope 2.5. I can probably work around it (although it means the next milestone release next week will be on b3 instead of b4), but I'd assumed that if one person who is using the beta triggered this issue, there will be plenty more who may be upset when they try porting their apps to 2.7.0 release. - -- Stuart Bishop <[EMAIL PROTECTED]> http://www.stuartbishop.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAB5kEAfqZj7rGN0oRAgGZAJ9gQe9xVX9pg/XdQKXpPVOruoD+/gCdG6vn V1SPuM5ZOpsmy+hpI94JGc4= =q473 -END PGP SIGNATURE- ___ 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 )