[Zope-Coders] Re: [Zope-dev] Speaking of 2.6...

[Brian Lloyd]

> The idea is to allow user to specify several points of presence (pop) 
> for an object. Does this break security? Probably yes, but in what case? 
> If an object from higly secure envionment appeared somewhere in 
> Anonymous zone, what then? Yes, Anonymous is able to alter object. But 
> there was reason for that!

Maybe - but maybe you just made the link without realizing 
the effect on security. That is one of the biggest conceptual 
problems here. Security behavior has to be as simple and 
understandable as possible for it to be useful. If people don't 
feel like they understand it, they will always have a nagging 
fear that they are vulnerable - and they will probably be right.

One could argue that we are already pushing the boundaries with 
the current security implementation, which is why the bar is so 
high for adding things to the core that potentially make things 
more complex yet.


> >Comparing it to Unix hard links is fine, but Unix doesn't 
> >use Acquisition to handle security, so the comparison is 
> >not apples-to-apples :) We need to spell out the exact semantics 
> >(*especially* wrt security, but also in terms of its effect on 
> >ZODB identity semantics, effects on undo, etc.)
> >
> Ok. I am not too well in English but I'll try to do my best. If it is 
> not hard for you give several words of explanation of "ZODB identity 
> semantics" and "effects on undo", not everything is clear for me.

Undo uses the "place" of an object as part of the criteria for 
deciding whether you can undo changes to it. If the meaning 
of "place" changes, undo behavior is likely to change. To use 
your earlier example, now Anonymous users might be able to undo 
changes made by a manager (in a different "place" on the "same" 
object). Is this acceptable? I don't know, but before we think 
about allowing changes like this into the core, the differences 
in behavior need to be spelled out in detail with specific examples.

Likewise with ZODB. What effects would links have on cache 
behavior (which are based on persistent identity)? On packing 
behavior? 


> Why we are not willing to allow such scenario? AFAIK there was and are a 
> lot of concernes refarding soft- and hardlinks in /tmp folder, with 
> sticky bit, etc... But they are usually solved with different means. 
> Yes, Zope and ZODB is much more complex. But why we have to limit 
> ourselves because something is difficult. 

I'm not trying to say that we shouldn't do something because 
it is difficult - just that in order to make changes like this 
we need to elaborate and understand all of the details and have 
a workable answer for all of the problems.


> Why not mark the feature as 
> experimental (red button, a lot of warnings, for instance) and make it 
> available to SuperManager only ;)

Because that's the textbook case for making it a Product :) We 
shouldn't be putting things in the core that come with flashing 
red warnings and can only be used by superusers.

What is wrong with leaving this as an add-on product? Why does 
it _need_ to be a part of the core at all? Useful products are 
useful, whether or not they "come with Zope", and there are 
plenty of very useful products that don't come built in.


Brian Lloyd        brian@zope.com
V.P. Engineering   540.361.1716       
Zope Corporation   http://www.zope.com