Brian Lloyd wrote: >> Both me and Myroslav Opyr <[EMAIL PROTECTED]> are quite >> commited to do the proposed "Object Links/References". Although >> from the emails we exchanged with you, I would've guessed that >> it was one of the "controversial enough" to be a Vetted item :-) >> >> Anyways I'm commited to do it. I do agree with your argument about >> link semantics but, at least for me, a link/reference is a link, and the >> semantics are perfectly defined i.e its not a RedirectObject. >> >> As in Unix, a hard link has different semantics from a soft link. I'm >> thinking of the "hard link" semantics. >> >I guess that what I was getting at is that the semantics >for this need to be spelled out in detail so that we can >make sure that they make sense before something like this >goes in. > Ok. Let's find out what we have and what we want. First of all we have strict hierarchy in ZODB where each object appears only once in the tree. Thus to access to an object it is only one way from root down to an object through containers. All security in Zope is based on that pattern. I am omitting Acquisition machinery to simplify (and I do not see it clearly in the context here).
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! Is Anonymous able to get out of the shared object to secure environment? No in no simple way. Sure if an object was DTML and Anonymous placed trojan horse in the script and someone from secure environment executed the code then we run in a problem. But we can warn user! And we have a lot of "Restricted..." techniques, maybe one can be applied here? >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. >Security in particular is very concerned with *containment* >path (rather than just acquisition path) in order to prevent >"stealing" access through acquisition wrappers. Having objects >with more than one "place" may introduce much the same problem, >so we'll need to write up in detail the effects on the security >machinery or its application to domain objects (or if the security >machinery does not need to change, we need to spell out why). > 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. Why not mark the feature as experimental (red button, a lot of warnings, for instance) and make it available to SuperManager only ;) I'd be glad to get feedback, thanks, Myroslav -- Myroslav Opyr zope.net.ua <http://zope.net.ua/> ° Ukrainian Zope Hosting e-mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> cell: +380 50.3174578 _______________________________________________ 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 )