On Apr 10, 2009, at 12:31 PM, Hanno Schlichting wrote:
> We are in the business of content management. The most valuable
> information the system and the entire physical machine has is the
> content in the system. You don't run web applications on any kind of
> shared servers where the system has any more valuable data.
> A person who is allowed to steal or delete the entire content is  
> what I call trusted. The potential additional damage of that person  
> breaking out of the web application is a minor concern compared to  
> this. Allowing any kind of TTW development is always going to be an  
> explicit opt-in, but if you are willing to allow this, we won't try  
> to stop you with limited access anymore.

So, it's quite black and white.

I would argue that there are several classes of users.  At least these:

1. Trusted users inside your organization that makes the software.The  
role they get through their credentials has highest trust level and  
they could be allowed to do the most TTW.

2. Trusted users inside your customer organization.  Those are usually  
the techies in the customer organization who configure your software  
to run the way they want.  The role they get through their credentials  
has some trust level.  They can change certain things TTW.

3. Untrusted users in your customer organization.  These users get a  
role through their credentials that allows them to configure the  
software parts, but cannot do any TTW changes.

4. Untrusted customers of your customer organization.  Plain web  
users.  They just view the content.

The granularity levels can be even finer between 1, 2, and 3 above.
This allows for various shades of grey.

However, since anybody's credentials can be stolen,  I do not want to  
allow rock changes and arbitrary imports even to the users in class 1  
above.  Because:

1. they have the highest trust level in that web app, but
2. they are just an ordinary user on a machine running that web app, and
3. there are people who have higher credentials on that machine --  

That's why leaving zope.security safer by default is the right thing.
If you want to allow more, wrap around it someorg.lesssecurity
or even someorg.nosecurity.


Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to