RE: [Zope-Coders] Re: [Zope-dev] Speaking of 2.6...
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 )
Re: [Zope-Coders] Re: [Zope-dev] Speaking of 2.6...
On Wed, 10 Apr 2002 01:30:56 +0300, Myroslav Opyr [EMAIL PROTECTED] wrote: Is Anonymous able to get out of the shared object to secure environment? User X is designated as a manager of folder /Xfolder. In todays Zope /Xfolder is a secure environment He has no authority over objects outside that folder, thanks to aq_inContextOf Can he create links to objects outside that folder? Links would be pretty useless if not. A common use case would be to create a link /XFolder/banner.gif to /stock_images/banners/mono.gif (for example). However if that is allowed, he now has management rights over that image object. I dont see how 'hard links' can possibly avoid this problem. Toby Dickenson [EMAIL PROTECTED] ___ 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 )
Re: [Zope-Coders] Re: [Zope-dev] Speaking of 2.6...
At 01:30 10-04-2002 +0300, Myroslav Opyr wrote: 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. The idea is to allow user to specify several points of presence (pop) for an object. Precisely. My first hack solves this and I've been using it OK in production sites. But I didnt like the fact that an object point of presence in the Zope tree was identical in every instance. That leads to confusion. My second hack creates a ProxyObject class thus allowing for a different metatype and a different icon. This reduces confusion. And you can also provide a management tab with links to the original object point of presence. I tried using Python 2.1 Proxy classes but Acquisition wasnt proxiable... C U! -- MV ___ 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 )
RE: [Zope-Coders] Re: [Zope-dev] Speaking of 2.6...
At 10:06 10-04-2002 -0400, Brian Lloyd wrote: 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. I totally agree. Thats what I previously thought was the case: that your earlier comments were very much towards the links stuff being Vetted and that it should be released as a patch/product. C U! -- MV ___ 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 )
Re: [Zope-Coders] Re: [Zope-dev] Speaking of 2.6...
At 15:12 10-04-2002 +0100, Toby Dickenson wrote: User X is designated as a manager of folder /Xfolder. In todays Zope /Xfolder is a secure environment He has no authority over objects outside that folder, thanks to aq_inContextOf Can he create links to objects outside that folder? No, he cant. To create a link (my hack...) you first need to obtain the object reference (moniker) with a Copy operation so that you can then do a Paste Ref. operation. Links would be pretty useless if not. No they wouldnt. A common use case would be to create a link /XFolder/banner.gif to /stock_images/banners/mono.gif (for example). However if that is allowed, he now has management rights over that image object. I dont see how 'hard links' can possibly avoid this problem. Right. But they would be useful to put an image in /Xfolder/images/ and then be able to paste links to it into /Xfolder/layout1/ and /Xfolder/layout2/ and /Xfolder/Development without the need to create multiples instances of the same image or without coding multiple requests for that object. C U! -- MV ___ 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 )
Re: [Zope-Coders] Re: [Zope-dev] Speaking of 2.6...
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 )
