Re: [Zope] Re: restricting permissions for direct access only
Michael Shulman wrote: I don't understand what inheriting proxy roles from callers has to do with allowing users to access protected resources above their user folders. They seem like totally different questions to me. Could you please explain? Nothing, different threads, crossed wires, nothing to see here ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: restricting permissions for direct access only
Tres Seaver wrote: The prior behavior (allowing users to access protected resources above the domain of their user folders) was a security hole caused by a bug, and was never documented as allowable: correcting it was a matter for a rather urgent fix, as it broke the explicitly-documented model. I don't think that's what Michael and I were commenting on... IIRC, if you had scripta calling scriptb, you used to be able to give scripta a proxy role and scriptb would also execute with that role. However, again IIRC, in current Zope releases, if you give scripta a proxy role, when it calls scriptb, scriptb will just run with the roles of the current user. Have I got this right? If so, I wonder why the change was made... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: restricting permissions for direct access only
David wrote: I just disagree. If theres a paranoia with the standard set of roles then prevent *those* from upward acquisition. But if I add a role *specifically* so it can access a common code pool, Security is hard enough as it is, special cases like this are something that Zoep 2 has enough fo already and certainly doesn't need any more... say like /commonPython and /commonJavascript thats available to sub-folders, probably distinquished by data adapter access to various companies ... than whats the downside? The upside is that I dont have to copy one code improvement across n number of sub-folder instances. I'm _sure_ there's a better way to solve your problem... Perhaps you could explain with a simple example what that problem is? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: restricting permissions for direct access only
I don't understand what inheriting proxy roles from callers has to do with allowing users to access protected resources above their user folders. They seem like totally different questions to me. Could you please explain? On 2/16/06, Tres Seaver [EMAIL PROTECTED] wrote: But... it's still not working for my real site. I think the issue is this. If script1 has proxy role Manager, and script2 has view permissions set only for Manager, then script1 can call script2, no problem. But if script1 instead calls script3, which then calls script2, it doesn't work unless script3 *also* has proxy role Manager. Yes, this was a deliberate change made a few major releases ago. I've never mich liked it myself for exactly the reason you describe. I wonder if anyone who knows could point out why this change was made, I'm sure the reasons were good... Even if the reasons were good, it would be nice to have an option to turn it on or off, even if the default is off. At the very least, it would be nice if this fact were documented. (Is it somewhere and I just missed it?) It surprised me very much, and it would have surprised and frustrated me even more if I'd written a site which worked and then later on decided to split off the functionality of some private script into a secondary one, unsuspecting that it would break the proxy roles setup. The prior behavior (allowing users to access protected resources above the domain of their user folders) was a security hole caused by a bug, and was never documented as allowable: correcting it was a matter for a rather urgent fix, as it broke the explicitly-documented model. The fact that folks wrote applications which relied on the hole is unfortunate; breaking them is better than leaving the sites built around the defined model vulnerable to abuse. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: restricting permissions for direct access only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: Tres Seaver wrote: The prior behavior (allowing users to access protected resources above the domain of their user folders) was a security hole caused by a bug, and was never documented as allowable: correcting it was a matter for a rather urgent fix, as it broke the explicitly-documented model. I don't think that's what Michael and I were commenting on... Sorry I misread -- I thought this was the I used to be able to acquire protected resources window. ;) IIRC, if you had scripta calling scriptb, you used to be able to give scripta a proxy role and scriptb would also execute with that role. However, again IIRC, in current Zope releases, if you give scripta a proxy role, when it calls scriptb, scriptb will just run with the roles of the current user. Have I got this right? If so, I wonder why the change was made... The only change I recall to how proxy roles work is that proxy roles used to *augment* a users' roles; now they *replace* them. I don't know that the case you are talking about (S1 has proxy roles, calls protected S2 fine, but fails when calling PR-less S3 which calls S2) ever worked under either scenario. Proxy roles have always only been checked for the topmost object on the executable stack (S1 in the first example, S2 in the second). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD9JJI+gerLs4ltQ4RAhxxAKDVqrtpzmNLAkqZe+3tBuCq2zXztACfeg+y kv0gjNpu5ap0Zl9OdhKzFRQ= =HqFe -END PGP SIGNATURE- ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: restricting permissions for direct access only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Shulman wrote: On 2/15/06, Chris Withers [EMAIL PROTECTED] wrote: But... it's still not working for my real site. I think the issue is this. If script1 has proxy role Manager, and script2 has view permissions set only for Manager, then script1 can call script2, no problem. But if script1 instead calls script3, which then calls script2, it doesn't work unless script3 *also* has proxy role Manager. Yes, this was a deliberate change made a few major releases ago. I've never mich liked it myself for exactly the reason you describe. I wonder if anyone who knows could point out why this change was made, I'm sure the reasons were good... Even if the reasons were good, it would be nice to have an option to turn it on or off, even if the default is off. At the very least, it would be nice if this fact were documented. (Is it somewhere and I just missed it?) It surprised me very much, and it would have surprised and frustrated me even more if I'd written a site which worked and then later on decided to split off the functionality of some private script into a secondary one, unsuspecting that it would break the proxy roles setup. The prior behavior (allowing users to access protected resources above the domain of their user folders) was a security hole caused by a bug, and was never documented as allowable: correcting it was a matter for a rather urgent fix, as it broke the explicitly-documented model. The fact that folks wrote applications which relied on the hole is unfortunate; breaking them is better than leaving the sites built around the defined model vulnerable to abuse. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD9ARc+gerLs4ltQ4RAudoAKC8EWZfw5AibQ+s/xmwtrXo2r0hvACgsYMF N+kPUlUZdjOYd9aL4pjfIaw= =v8Ky -END PGP SIGNATURE- ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: restricting permissions for direct access only
Michael Shulman wrote: Hi, I am new to Zope, and so far I like it very much. But I think I am confused about how security works, or is supposed to work. Specifically I want to know the following. Is there a way in Zope to restrict permissions for direct access only (i.e. calling an object through the web) but still allow indirect access (i.e. executing an object that was called by another object that was called through the web)? Objects called by a URL have a REQUEST parameter. What I usually do is make the script accept an optional REQUEST=None, and if it's non-None then I raise Unauthorized. Florent I have many Zope scripts but most of them are only auxiliary functions; only a few are designed to be accessed by a user through a URL. I don't want users to be able to call my auxiliary scripts directly, only the ones that are designed to be published. But changing the security settings on the auxiliary scripts (e.g. removing View access from Anonymous role) prevents anonymous users from executing them even indirectly, so the public objects which depend on those auxiliary methods also stop working. Feel free to tell me that I am misunderstanding the way security works, or is supposed to work, in Zope, or that if this is something I need to do I am designing my site incorrectly from the point of view of Zope security (and if so, what is the correct way to design it?). Thanks!! Mike -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
