Tino Wildenhain wrote:
I want to have full access rights on the database through the
Usually you dont want that.
Yes, usually i don't.
Sane security constrains on database save you a lot mistakes if done
right. You can also use views and stored
functions to further tighten your security.
Really, this reasoning may apply on regular projects.
For my case, let me explain:
- Say, you want to read/write a DB through Zope.
- You have a read-only ZODB, so you cannot change anything.
- The user-folder is based on an external authentication mechanism.
- A Zope security hole comes up, which gives you all permissions within
- You want to minimize the casualties of this attack.
I think database constrains are not applicable for this scenario. Also,
i don't want any application logic within the database, so stored
procedures are not an option either. I believe that using ZSQLmethods
for this setup will/might allow an attacker to:
- retrieve information about the database (schema-wise) [ <- not so
- retrieve/modify records [ <- much more important ]
I (maybe falsely) think Zope as a "sandbox" environment. I cannot
"operate" as root within this sandbox, so i need external methods. Why
not moving all my "non-restricting"/"privileged" actions outside this
sandbox, so that if someone breaks-in the sandbox i might stand a better
chance to keep him there for a while longer? Following this reasoning, i
created a single external method [a true SPOF :-) ] which does all the
Bad done external methods are more likely to open security holes.
Of course! I trust the Zope developers to be much more of a coder than
I really hope i don't! :-) As Dieter said, my application is not a
conventional Zope application.
What is it instead? :)
Got you intrigued huh?? :-)
It is a webmin/usermin-like suite for Linux. The approach is quite
different, both commercially and architecturally. I am pretty sure it is
probably the most "unconventional" use of Zope up to now. :-)
I could say that, for this project, i am using Zope:
- as a much safer alternative to CGI
but not if compromized :)
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -