[Zope3-dev] inherited security (and timezones)

[Stephan Richter]

On Thursday 25 August 2005 23:50, Gary Poster wrote:
> Jim mentioned to me a while ago that he was planning to have security  
> settings for classes inherit.  I was against it, because I thought  
> that like_class answered the use case sufficiently, explicitly, and  
> not overly annoyingly.
>
> However, in order to get pytz timezones--a large set of automatically  
> generated classes that potentially change every quarter--to do what  
> we want without that, I only see monkeypatches. :-/  So I'm +1 on  
> inherited security I guess.

I am +1, *if* it can be overwritten, which I think it would. On the other 
hand, this change would need to be extremely well documented. For example, 
imagine we give BTreeContainer some permission for its method, then pretty 
much all our containers will have those permissions. Sometimes I specifically 
do not declare a permission because I never want a certain method to be 
accessed. This would mean we would have to explicitly be able to turn off a 
permission in a derived class. Of course, I could just create a permission 
that is never given to any principal, something like zope.noaccess, which 
would be the opposite to zope.public.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training