[Zope] RFC: backward compatibility of PythonScript bindings for 2.6.4 / 2.7.0

[Brian Lloyd]

Hi all - 

We recently made Zope 2.6.4-rc1 and 2.7.0-rc1 releases which fix 
a number of issues that were introduced in the Q4 security audit 
work and the resulting 2.6.3 and 2.7.0-b4 releases.

The initial feedback is very good, and at this point I am aware of 
only one outstanding issue - but it is a sticky one and I want to 
get some community feedback before deciding exactly how to address 
it.

Background: one of the holes fixed in the security audit was that 
the current user's access to 'context' and 'container' in a Python 
Script was not checked when those names were bound to the script 
for execution. This meant that theoretically a script could have 
a handle to an object (like the script container) that the user 
really didn't have permission for. Subsequent attribute accesses 
or attempted method calls would likely still fail since a security 
check *would* be performed on those actions, but in principle the 
script shouldn't have been allowed to get that initial handle to 
the object.

The fix for this was straightforward - do a security check on 
'context' and 'container' before binding those objects when the 
script is getting ready to execute.

While this is definitely the Right Thing To Do (tm) from a 
security standpoint, it poses a bit of a backwards compatibility 
problem because:

  - By default, all Python Scripts bind both 'context' and 
    'container'. This means that all existing Python Scripts 
    in applications, portal tools, etc. have those bindings unless 
    they have been manually changed.

  - A standard CMF / Plone idiom is to put scripts inside of portal 
    tools (workflow is a primary example). Very often the users who 
    execute the scripts (as a part of workflow, for example) **do not 
    have access to the tool containing the scripts**.

These two facts did not cause a problem before, because the security  
check for the 'container' binding was not being performed at bind-time. 

Now that it is, many scripts will not work because the user will not 
have access to the tool containing the script. Worse, the binding 
check will cause an unauthorized error **even if the script doesn't 
actually use the 'container' variable, because all existing Python 
Scripts already have that binding defined by default ;(

So as things stand, the way the binding check currently works will 
cause problems for most everyone using a workflow tool or other 
tools containing scripts where the user doesn't have access to the 
script container (the tool itself). This is likely to be a fairly 
large number of people / sites.

I'd like to propose a solution that will hopefully affect far fewer 
people, while still doing the right thing with regard to security.

Currently, if the executing user does not have access to either 
'context' or 'container', an Unauthorized exception will be raised 
at bind-time. *This will happen even if the script does not use 
either of those names*, which is the root of the problem.

I propose to change that behavior so that if the security check on 
either 'context' or 'container' fails, that name will be bound to 
None rather than raise an Unauthorized. The effect of that change 
on existing sites would be:

  - Existing scripts living in tools which *don't* reference 
    'container' in their code will continue to work as before 
    without any changes on the part of the site admin

  - Existing scripts that *do* refer to 'container' in their 
    code (and if the user doesn't have access to it) will 
    break, since 'container' will now be 'None' rather than 
    what the script thought it would be. The fix for such 
    sites is to make sure the user has the appropriate access 
    on the script container.


What I like about this is that it potentially requires direct 
action from fewer site admins. IOW, you only have to fix your 
permissions if you were already doing something that the security 
system should have been preventing before.

What I don't like is that it is somewhat magical, and now the 
error you would get (probably 'None has no attribute xxx') if 
the user doesn't have access to the container doesn't tell you 
the real problem. 

That is likely to be compounded by the fact that some site admins 
will be saved from having to care immediately by this magic, then 
run into it later, when they might be thoroughly confused if they 
didn't happen to read this thread as it went by ;)

The alternative is to take the 'hard-line' and say that site 
admins need to visit their script containers and ensure that 
either a) the users of the scripts have the appropriate 
permissions on the container or b) they remove the 'container' 
binding from their scripts if it is not appropriate to give 
the users access to the script container.

Sorry this was so long, but I think these kinds of backward 
compatibility vs. consistency conundrums require some community 
buy-in on the path chosen, since *someone* will be unhappy and 
have to do some manual fixing no matter what.

Thoughts?



Brian Lloyd        brian at zope.com
V.P. Engineering   540.361.1716              
Zope Corporation   http://www.zope.com