Re: [Zope] restricting permissions for direct access only
Michael Shulman wrote:
Okay, I must be the most moronic user ever. The default text in a newly created Python Script, which I did not bother to change for my test case, accesses meta_type, but I did not notice this; thus I was confused. (Just out of curiosity, what permissions are required to access meta_type?)
Depends, should be 'View', or most likely not protected at all, but I guess you found an object where it was protected with something else...
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...
Is there a way to make scripts inherit proxy roles from their callers?
Both I and you wish there was ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 2/15/06, Chris Withers <chris@simplistix.co.uk> 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. Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Shulman wrote:
On 2/15/06, Chris Withers <chris@simplistix.co.uk> 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 tseaver@palladion.com Palladion Software "Excellence by Design" http://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-----
Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michael Shulman wrote:
On 2/15/06, Chris Withers <chris@simplistix.co.uk> 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. -
Hi Tres, 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, 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. David
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
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
-----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 tseaver@palladion.com Palladion Software "Excellence by Design" http://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-----
Tres Seaver wrote:
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.
Yeah, I wonder if that means if you give it a proxy role of manager, it looses all other roles?
I don't know that the case you are talking about (S1 has proxy roles, calls protected S2 fine,
Okay, S2 here is "some permission-protected method where the current user doesn't have the required permission"...
but fails when calling PR-less S3 which calls S2) ever worked under either scenario.
Oh well, I could have sworn it did at one point :-/
Proxy roles have always only been checked for the "topmost" object on the executable stack (S1 in the first example, S2 in the second).
Is it something worth adding as a feature request or are there security implications I'm missing? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (4)
-
Chris Withers -
David -
Michael Shulman -
Tres Seaver