Re: [Zope-dev] Re: Security audit introduced problem in PageTemplates/Expression.py

[Stuart Bishop]

-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 )

Re: [Zope-dev] 2.7 management_page_charset cannot be callable anymore

[Toby Dickenson]

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 )

[Zope-dev] localfs and zope 2.7 (was: Re: 2.7 assertion with CVS of that morning two)

[Bakhtiar A Hamid]

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] Re: Security audit introduced problem in PageTemplates/Expression.py

[Jim Fulton]

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] Zope-2.6.3 issue with CMF-1.3.3 portal_types

[Erik A . Dahl]

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 string, 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 )

[Zope-dev] Re: Zope-2.6.3 issue with CMF-1.3.3 portal_types

[Tres Seaver]

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 string, 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] [ZConfig] elementary function framework and env function

[Dieter Maurer]

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:
+'''encapsulates a function call substitution.
+
+A function call has the 

RE: [Zope-dev] win32 setup sources

[Brian Lloyd]

 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 )

RE: [Zope-dev] win32 setup sources

[Chris McDonough]

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 )

[Zope-dev] Re: CVS: Releases/Zope/lib/python/ZEO - simul.py:1.12.8.2.18.18

[Tres Seaver]

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] Re: CVS: Releases/Zope/lib/python/ZEO - simul.py:1.12.8.2.18.18

[Jeremy Hylton]

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 )

Re: [Zope-dev] Re: CVS: Releases/Zope/lib/python/ZEO - simul.py:1.12.8.2.18.18

[Paul Winkler]

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 )

[Zope-dev] Re: CVS: Releases/Zope/lib/python/ZEO - simul.py:1.12.8.2.18.18

[Tres Seaver]

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] 2.7 management_page_charset cannot be callable anymore

[Hajime Nakagami]

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.6r2=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 )

Re: [Zope-dev] Re: Security audit introduced problem in PageTemplates/Expression.py

[Jim Fulton]

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] Re: Security audit introduced problem in PageTemplates/Expression.py

[Jim Fulton]

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 )