> 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 [EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )