Dieter Maurer wrote:
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).

I don't see this as blurred at all. A sequence is, mathematically, a special case of a mapping.

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 question whether there is a need to check "whether access should be granted to individual items in a mapping".

I suggest that such flexibility makes the security system needlessly

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.

Ah, so you are arguing that the handler should simply not be called for item access. I can buy that. I don't think that would make Stuart happy though. :)

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 assume that you are refering to the security policy.

* 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

These are valid points. This should be documented much better than it has been. I'll note that both of the things you ask about relate to no-longer used features of the security policy.

I'll make an attempt at a brief

- The *original* reason for the accessed and validate parameters was
  to permit the distinction between acquired and non-acquired
  attributes.  As a comment in the security policy code notes,
  we no-longer pay any attention to the accessed argument.

- The *original* use for the 0 return value from the security
  policy was to suggest that, although access to the value provided
  was unauthorized, the application might provide a different value
  that would be.  This was to support a questionable feature of
  trying to acquire another value of the first value found through
  acquisition was unauthorized.  The current Zope security policy
  never returns 0.

Much of the complexity in the Zope 2 security policy has to do with:

- The fact that the security system is based on looking at
  assertions for values, and

- The fact that we can't make assertions on immutable values
  (e.g. strings).

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

Maybe, we should change this for Zope 3?

In Zope 3 (and, I hope 2.9), it will be easier to make security assertions about things you can't make assertions about now.

The fundamental change in Zope 3 is that we make assertions
about *names*, not values.  This makes it possible to talk about
access to attributes whose values are strings. Essentially, we
are placing the resytictions on the *access*, not the values.

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

A mistake in Zope 2, we've made the mistake of trying to provide backward compatability at almost any cost. This has led to parts of the framework being far more complicated than it should be.

In the future, we've got to do a better job of managing change
so that we can clean things up.

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, security related rules are important enough that
they deserve thourough and prominent specification/documentation.

Yup. We are certainly trying to do a good job of this in Zope 3. I hope that, in the near furture, we can merge some aspects of the Zope 2 and Zope 3 security architectures.


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation

Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to