[Zope-dev] Suggestion for small(?) change in BaseRequest.py. Security effects?
First Explanation:
==
We have been discussing how to implement the challenge support in
PluggableAuthService, and I have been trying a couple of different ways.
(Note: challenge-support in this context means, how to ask the client
for authenticifcation credentials, that is username and password, or
tickets, or certificates, or something.)
The preferred solution has been narrowed down to using a way similar to
CookieCrumbler, that is, replacing the current response-objects
unauthorized() method with a method that does the challenge, like so:
if not req.get('disable_cookie_login__', 0):
if attempt == ATTEMPT_LOGIN or attempt == ATTEMPT_NONE \
or attempt == ATTEMPT_RESUME:
# Modify the unauthorized response.
req._hold(ResponseCleanup(resp))
resp.unauthorized = self.unauthorized
resp._unauthorized = self._unauthorized
Now, there is one tiny problem with that, and that problem is in
BaseRequest.Traverse(). (BaseRequest.py, line 438):
if user is None and roles != UNSPECIFIED_ROLES:
response.unauthorized()
if user is not None:
...
As you see, this code assumes that response.unauthorized will raise an
error. If it does not, the code will continue *as if the user is
validated*. An error will occur later, since the user isn't validated,
so it's nota security hole (is think), but it causes a problem:
The only acceptable end of an unauthortized() is to raise an exception.
This means in practice, either the Unauthorized exception that prpvoces
the standasd 401 login box challenge, or a Redirect to a login page.
This seems a bit limiting, and there has been requests for doing other
things, such as returning an HTML form directly, and whatnot.
Then, suggestion:
=
My tests seems to show that inserting a return after the unauthorized
call above:
if user is None and roles != UNSPECIFIED_ROLES:
response.unauthorized()
return
will solve this issue. It is now possible to NOT raise an exception in
unauthorized and still not get problems. Instead, you can now to a
RESPONSE.redirect(), or you can replace the body with setBody for a
login form, or something like that.
I haven't been able to find any other code that continues after an
unathorized call, so this should be the only place. Also, during normal
operation, it is obvuiosly a safe bet. The change in itself has no nasty
side effects.
Last, questions:
Are there any other problems with NOT raising an exception in
unathorized(). Becuase if there is, we probably limit the possible
challenge responses to a redirect, and then this change makes no difference.
I would suggest that the change goes in ANYWAY, to stop people almost
accessing stuff by fiddling with response.unauthorized (although I admit
I don't know how to do that).
Lennart Regebro
___
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] portal_actions via listFilteredActionsFor
This is a question for a plone list. But you'll probably need to understand Zope's security machinery better to get a handle on what you need to do. Read this: http://zope.org/Documentation/Books/ZopeBook/2_6Edition/Security.stx cheers, Chris PS: Please note, this list is for development OF, not WITH Zope. Krzysztof Kubacki wrote: Hallo, I have the problem. Zope 2.7.0, Plone-2.0.3, Linux I list actions from portal_actions actions python: here.portal_actions.listFilteredActionsFor(here) I recive a list with actions. Depending on kind of logged user I recive that list in diffrent count. I mean that when I'm Manager the list is bigger than I'm SiteManager. I suppose that it depends on permissions. Where I can set it? I would like to recive the same list being Manager and SiteManage as well. Thanks in advance KK ___ 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 ) -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] Zope MemoryError after installing Plone
Matt Shaw wrote: I just compiled a fresh copy of zope 2.7 - it started up just fine. So then I grabbed Plone 2.0.4. After copying Plone to my Products directly, I cannot startup Zope and I get a MemoryError. Here is the tb: http://paste.plone.org/1317 Tehn maybe you should ask on a Plone list ;-) I'm using python 2.3.3 on freebsd4 - Do I need recompile python with some special flag? ...but this could, of course, be the python on freebsd compiled with too small a stack size bug, for which you may wish to search the list archives... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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: Developing plugins for PluggableAuthService
Lennart Regebro wrote: OK, Thanks. I'm noticing that (with Zope 2.7.2) when I do this, I do not get the modulname (whatever) nor the exception level WARNING printed to the log. Is this a config error, or am I doing something wrong? Because quite obviously, it should be there, right? You're not doing anything wrong, but arguably it is a config error. You'll need to tweak your log format string for the log in question in zope.conf. The real problem here is that, for some reason that I don't get, zLOG sticks the WARNING in the *message* to be logged when it calls the underlying python logger. I wish someone would explain why it does this, as it means you either get double inclusion of the logging level for stuff logged by zLOG or, as you've experienced, a missing level when code logs things the correct way... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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: Developing plugins for PluggableAuthService
Chris Withers wrote: You're not doing anything wrong, but arguably it is a config error. You'll need to tweak your log format string for the log in question in zope.conf. The real problem here is that, for some reason that I don't get, zLOG sticks the WARNING in the *message* to be logged when it calls the underlying python logger. I wish someone would explain why it does this, as it means you either get double inclusion of the logging level for stuff logged by zLOG or, as you've experienced, a missing level when code logs things the correct way... Somebody can fix that for 2.8 tomorrow, maybe? But I guess I can check in the LOG changes to PAS now, anyway. ___ 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] Suggestion for small(?) change in BaseRequest.py. Security effects?
On Thu, 2004-09-02 at 12:38, Lennart Regebro wrote: ... Then, suggestion: = My tests seems to show that inserting a return after the unauthorized call above: if user is None and roles != UNSPECIFIED_ROLES: response.unauthorized() return will solve this issue. It is now possible to NOT raise an exception in unauthorized and still not get problems. Instead, you can now to a RESPONSE.redirect(), or you can replace the body with setBody for a login form, or something like that. I haven't been able to find any other code that continues after an unathorized call, so this should be the only place. Also, during normal operation, it is obvuiosly a safe bet. The change in itself has no nasty side effects. I'd add a transaction rollback before return actually, which is the normal behavior when an exception is raised like Redirect or Unauthorized So if the situation is: user is anonymous or has insufficient rights on a object which is handled after some changes are made to objects, the challenge will take place and rolls back all these changes which should not have taken place for that user. so: if user is None and roles != UNSPECIFIED_ROLES: response.unauthorized() get_transaction().abort() return should do the trick. Regards Tino Wildenhain ___ 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] Suggestion for small(?) change in BaseRequest.py. Security effects?
Lennart Regebro wrote at 2004-9-2 12:38 +0200: ... Are there any other problems with NOT raising an exception in unathorized(). Becuase if there is, we probably limit the possible challenge responses to a redirect, and then this change makes no difference. If the traversal made any changes to persistent state, then these changes are committed rather than aborted. Usually, traversal should not change the persistent state -- but... -- Dieter ___ 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 )
