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

[Myroslav Opyr]

Brian Lloyd wrote:

>> Both me and Myroslav Opyr <myroslav@zope.net.ua> 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 t=
he
>> 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.=20
>>
>I guess that what I was getting at is that the semantics=20
>for this need to be spelled out in detail so that we can=20
>make sure that they make sense before something like this=20
>goes in.
>
Ok. Let's find out what we have and what we want. First of all we have=20
strict hierarchy in ZODB where each object appears only once in the=20
tree. Thus to access to an object it is only one way from root down to=20
an object through containers. All security in Zope is based on that=20
pattern. I am omitting Acquisition machinery to simplify (and I do not=20
see it clearly in the context here).

The idea is to allow user to specify several points of presence (pop)=20
for an object. Does this break security? Probably yes, but in what case?=20
If an object from higly secure envionment appeared somewhere in=20
Anonymous zone, what then? Yes, Anonymous is able to alter object. But=20
there was reason for that! Is Anonymous able to get out of the shared=20
object to secure environment? No in no simple way. Sure if an object was=20
DTML and Anonymous placed trojan horse in the script and someone from=20
secure environment executed the code then we run in a problem. But we=20
can warn user! And we have a lot of "Restricted..." techniques, maybe=20
one can be applied here?

>Comparing it to Unix hard links is fine, but Unix doesn't=20
>use Acquisition to handle security, so the comparison is=20
>not apples-to-apples :) We need to spell out the exact semantics=20
>(*especially* wrt security, but also in terms of its effect on=20
>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=20
not hard for you give several words of explanation of "ZODB identity=20
semantics" and "effects on undo", not everything is clear for me.

>Security in particular is very concerned with *containment*=20
>path (rather than just acquisition path) in order to prevent=20
>"stealing" access through acquisition wrappers. Having objects=20
>with more than one "place" may introduce much the same problem,=20
>so we'll need to write up in detail the effects on the security=20
>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=20
lot of concernes refarding soft- and hardlinks in /tmp folder, with=20
sticky bit, etc... But they are usually solved with different means.=20
Yes, Zope and ZODB is much more complex. But why we have to limit=20
ourselves because something is difficult. Why not mark the feature as=20
experimental (red button, a lot of warnings, for instance) and make it=20
available to SuperManager only ;)

I'd be glad to get feedback, thanks,

Myroslav
--=20
Myroslav Opyr
zope.net.ua <http://zope.net.ua/> =B0 Ukrainian Zope Hosting
e-mail: myroslav@zope.net.ua <mailto:myroslav@zope.net.ua>
cell: +380 50.3174578