Unexpected authorization failure during traversal

Bug #143376 reported by Frank Bennett
2
Affects Status Importance Assigned to Milestone
Zope 2
Invalid
Medium
Unassigned

Bug Description

CHANGES.txt in Zope 2.7.5 final (2005/03/20), contains the following entry:

  * AccessControl/User.py: _check_context() has not been
    called for authenticated users.

The corresponding change produces unexpected authorization failure during traversal. Code which ran without error under previous versions of Zope fails under 2.7.5-final.

The behavior can be reproduced as follows:

 1. Install Zope-2.7.5-final and bring up an instance
    with default settings;

 2. Create a folder and subfolder, "/a/b".

 3. Create a user folder acl_users at top level,
    and create a user User1 in it.

 3. Place a method "m1" at top level, which accesses
    properties of its context.

 4. In the securities tab, make the following two changes:

    - Deny the View permission the the Anonymous role;
      and

    - Explicitly grant all permissions to Authenticated,
      including View.

 5. Log in as User1.

 5. Access the following path: /a/b/m1

 6. The result on our installation of 2.7.5-final is
    an authentication error:

      You are not authorized to access this resource
      Username and password are not correct. (Also, an
      error occurred while attempting to render the
      standard error message.)

This does not seem to be correct behavior. Zope versions prior to 2.7.5-final run this case without error.

The Japanese colleague on whose behalf I am filing this issue (Tokuyasu Kakuta) suggests unwinding the change by replacing lines 185 and 186 in Users.py with " return 1". This restores the previous behavior.

Revision history for this message
Tres Seaver (tseaver) wrote :

Thank you for the detailed report. Unfortunately, I am unable
to reproduce your error against the head of the 2.7 branch,
which has the same code in User.py as 2.7.5.

Here is some additional detail about my attempts:

  - In step 3, you do not specify the kind of access which
    the method makes of its context. Here is the text of
    the PythonScript I used
    (http://localhost:8080/m1/document_src)::

      ## Script (Python) "m1"
      ##bind container=container
      ##bind context=context
      ##bind namespace=
      ##bind script=script
      ##bind subpath=traverse_subpath
      ##parameters=
      ##title=
      ##
      return context.title_or_id()

  - In step 4, you don't specify whether you are making the
    changes to the "Security" tabl of the root folder or of
    either '/a' or '/a/b'. I tried both the root folder,
    and also '/a' (where I had to clear the "Acquire" field.

  - In step 5, you say "Log in as User1"; I don't know how
    you mean to do that (User1 has no roles at all on my system).

  - I pasted the following URL into a new browser session:

      http://localhost:8080/a/b/m1

    got challenged for HTTP basic auth, entered 'User1' and
    the corresponding password, and was able to see the title
    of the 'b' subfolder without further challenge.

Revision history for this message
Frank Bennett (bierce) wrote :

I mistranscribed my colleague's description of the error; it was careless of me to file a report without confirming the behavior myself. With apologies, once more, with feeling. :-)

Zope 2.7.5-final and 2.7.3b1 (both compiled for Python 2.3.5) behave differently when treated as follows:

 1. Install and run Zope

 2. At top level, create a folder "a"

 3. At top level, create a method that accesses
    context (a script that returns
    context.title_or_id() will do the trick)

 4. At top level, explicitly grant all permissions
    to "Authorized".

 5. At top level, deny View permission to "Anonymous".

 3. Create a user folder inside folder "a", with a
    user User1. (User1 can be assigned one or more
    roles or not.)

 4. Logout, and access the path /a/b/m1 as you had
    done before.

Under 2.5.3b1 Zope returns the id ("b") after the authorization challenge. Under 2.5.7-final, authorization fails. If the method "m1" is cut and pasted into "a" or "b", then of course login succeeds.

It looks as though methods can no longer be shared across authentication realms (if I have expressed that correctly -- I'm not a computer scientist). It is not clear to us why that should do so. User1 is authenticated to the system, and is not attempting to access context outside the bounds of her authentication.

There may be a very good reason for this change in traversal behavior, but it is not obvious to us what that might be; and the change is consequential for my colleague (i.e. it has interrupted a planned migration from 2.6 to 2.7). If this issue was documented in the release notes -- apart from the telegraphic entry in CHANGES.txt -- we haven't found mention of it anywhere. We're curious to know how the change works an improvement.

Revision history for this message
Frank Bennett (bierce) wrote :

(Erratum to Entry 3: as step 2a, create a folder "b" inside folder "a".)

Revision history for this message
Tres Seaver (tseaver) wrote :

I am unable to reproduce this on a recent Zope instance (2.12 branch tip)::

 $ bin/mkzopeinstance -d /tmp/lp143376 -u zope:r00ler
 $ /tmp/lp143376/bin/zopectl fg
 /tmp/lp143376/bin/runzope -X debug-mode=on
 2010-04-12 09:16:38 INFO ZServer HTTP server started at Mon Apr 12 09:16:38 2010
  Hostname: 0.0.0.0
  Port: 8080
 2010-04-12 09:16:41 INFO Zope Ready to handle requests

then, in the browser:

 /manage_addFolder?id=a
 /a/manage_addUserFolder
 /a/acl_users/manage_users # added 'user1', with password '123'
 /a/manage_addFolder?id=b
 /a/manage_addPageTemplate?id=index_html # default template uses 'here/title_or_id'
 /manage_changePermissions # give 'Authenticated' all permissions of 'Anonymous'
                                             # and clear 'Anonymous'

At this point, I can point another browser at '/a/', get challenged, provide the 'user1:123' credentials, and see the page.

Changed in zope2:
status: New → Incomplete
Revision history for this message
Colin Watson (cjwatson) wrote :

The zope2 project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope2.

Changed in zope2:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.