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 Opyr <>  Ukrainian Zope Hosting
cell: +380 50.3174578

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to