So... remember way back when Brian warned about the binding breakage
due to the improved security checks?  It just bit me in a way I didn't
forsee.  I forgot that PageTemplates use bindings too, which means
those changes affect more than just PythonScripts they affect Products
that use PageTemplateFile methods.  My product had declared its object
instances to be private, and in doing so it totally breaks the ability
to use PageTemplateFile methods.  This sucks.

Using DTML for product methods goes against the fiber of my being, I
just can't bring myself to do it; the namespace pollution as
programing paradigm is so frustrating it just makes me want to throw
things.  But DTMLFile has a huge advantage ... it does the Right Thing
with respect to Zope security.  It ignores it completely.

Paradoxically, by ignoring Zope's security framework in the context of
on-disk methods this actually improves Zope's overall security.  It
allows you to fully take advantage of the API seperation available to
Products.  To briefly enumerate, you've got 3 basic types of methods:

def _python_only_methods():
    """docstring doesn't "matter" as this can't be published or
       accessed TTW, security declarations are superfluous, can't be
       accessed by RestrictedPython either"""

def python_or_RestrictedPython_methods():
    # no docstring ensures its not publishable, security declarations
    # are necessary to dictate RestrictedPython's privileges

def publishable_python_or_RestrictedPython_methods():
    """docstring dictates publishablility, security declarations are
       necessary and dictate both RestrictedPython's privileges and TTW

Now DTMLFile does its work with the privileges of "python" code, which
is great because it means you can define methods which generate
content fragments without any restrictions on what APIs it can and
can't use.  This is useful--more on why in a sec.

Conversely the PageTemplateFile does it work with the privileges of
"RestrictedPython" code, which might seem great at first, ("More
security? What can possibly be bad about that?!") but rapidly wears
thin when you try to use PageTemplateFiles in API code, and screws
Product authors who were trying to write secure code.

To illustrate the first point where PageTemplateFile forces a weakened
API, consider the case of Tabs.manage_tabs() ... this method must be
declared *public* so that Products using PageTemplateFile can access
it.  The caller's security context is taken into account with
PageTemplateFiles and as 2 different products using PageTemplateFile
methods might require completely different permissions to access the
method which in turn relies upon Tabs.manage_tabs() the only way to
satisfy all possible permission combinations is to just give up and
declare the method public so it always succeeds.  Products using
DTMLFile OTOH don't care, it could be totally private, as it *should*
be, and DTMLFile methods would still be able to call it and use the
results to display content without regards to callers security
context, this makes DTMLFiles useful because you can maintain the
integrity of your API and not expose stuff to RestrictedPython that
true RestrictedPython has no business calling.  If only DTML wasn't
such a horrible, syntactically braindamaged, stack-bound HELL to work

But DTML is hell, and thats not going to change, its better to focus
energies on the future which is ZPT, and I assert that
PageTemplateFile behavior needs to change.

Back to the second point, that the current behavior screws Product
authors trying to write secure code.  My product called
security.declareObjectPrivate() because this is the only way I know of
to ensure a product and its attributes are safe from tampering,
and until the Binding changes, I thought this was a great deal.  Now
that the hole in bindings have been fixed though it turns out that
because my product uses PageTemplateFile methods which in turn pay
attention to bindings, and, unfortunately, pay attention to the
callers security context as well, none of those methods work anymore,
they raise Unauthorized: Not authorized to access binding: container

I can fix this by changing my object security declaration to be public
or restricted to a permission, but that has side effects that I don't
want, namely opening my object instances up to tampering from within
RestrictedPython given the appropriate security context.  Given that
my need to have the object instance completely private and my desire
to avoid DTML are now in direct conflict I'm basically forced to
choose between a range of compromises and I don't like any of them.

So here's the questions I have for you all... is there a way to
declare appropriate security on the bindings that are screwing me
right now from within my product code so that I can selectively poke
holes to allow container access where needed, or am I to be forcibly
coerced into exposing my object to restricted code?  And two, assuming
I haven't overlooked some detail about why forcing PageTemplateFile to
work within the calling security context is a good thing...  Shouldn't
we fix PageTemplateFile to work like DTMLFile wrt security?  How hard
is it going to be to do that?

Jamie Heilman           
"...thats the metaphorical equivalent of flopping your wedding tackle
 into a lion's mouth and flicking his lovespuds with a wet towel, pure
 insanity..."                                           -Rimmer

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

Reply via email to