RFClarification: Security on Product Attributes
Hi, If I have the following lines in a Python Product: def __init__(self, id): """initialise a new instance of product""" self.id = id self.title = 'Title!' self.anInt = 0 self.aString = 'testing' Are these attributes protected by the security machinery? If so, how so? Can I read them? I think the answer is yes for anInt and no for aString. Don't know the mechanics of title and id, I'm guessing they're going to be special cases whatever... Are they protectable by permissions? I do hope so although my experience is that, at best, it's not necessary, which is contrary towhat I thought the new security policy was. Should they have to be protected by permissions? Probably... Looking for comments-ly, Chris
If I have the following lines in a Python Product:
def __init__(self, id): """initialise a new instance of product""" self.id = id self.title = 'Title!' self.anInt = 0 self.aString = 'testing'
Are these attributes protected by the security machinery? If so, how so?
Chris - I've verified (any of my previous comments to the contrary) that simple attributes (python types) do not really play in the permissions machinery. The canonical way to expose such things for now is to expose them through method calls (which can play in the permissions scheme). Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
At 12:27 PM 10/4/00 -0400, Brian Lloyd wrote:
I've verified (any of my previous comments to the contrary) that simple attributes (python types) do not really play in the permissions machinery. The canonical way to expose such things for now is to expose them through method calls (which can play in the permissions scheme).
IIRC, this stuff got broken by the switch to the new security machinery. ZopeSecurityPolicy doesn't check 'foo__roles__' on the parent object the way ZPublisher does/did.
"Phillip J. Eby" wrote:
IIRC, this stuff got broken by the switch to the new security machinery. ZopeSecurityPolicy doesn't check 'foo__roles__' on the parent object the way ZPublisher does/did.
Can anyone say why? cheers, Chris PS: Will the new new security stuff (still in proposal stage, IIRC) start checking this stuff again?
"Phillip J. Eby" wrote:
At 12:27 PM 10/4/00 -0400, Brian Lloyd wrote:
I've verified (any of my previous comments to the contrary) that simple attributes (python types) do not really play in the permissions machinery. The canonical way to expose such things for now is to expose them through method calls (which can play in the permissions scheme).
IIRC, this stuff got broken by the switch to the new security machinery. ZopeSecurityPolicy doesn't check 'foo__roles__' on the parent object the way ZPublisher does/did.
It never did. Before the switch to the new policy machinery, most attributes that don't have roles were unprotected. Now, we at least have a way to make some assertions. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Chris Withers wrote:
Hi,
If I have the following lines in a Python Product:
def __init__(self, id): """initialise a new instance of product""" self.id = id self.title = 'Title!' self.anInt = 0 self.aString = 'testing'
Are these attributes protected by the security machinery? If so, how so?
Yes. There are two ways of protecting objects, depending on whether they (can) have a __roles__ attribute. None of the values above can have a __roles__ attribute, so they are covered by assertions made in their containers. See http://www.zope.org/Members/michel/Projects/Interfaces/ZopeSecurityPolicy Note that if you can't adequately control something that can't have __roles__, you can provide an access function (e.g. getAnInt), which you can control
Can I read them? I think the answer is yes for anInt and no for aString.
Probably, if you can get at one, you can get at the other.
Don't know the mechanics of title and id, I'm guessing they're going to be special cases whatever...
Nope, except that we may provide separate accessors (e.g. getId).
Are they protectable by permissions? I do hope so although my experience is that, at best, it's not necessary, which is contrary towhat I thought the new security policy was.
The goal of the new security policy was to: - Centralize authorization policies - Begin the tightening of access to attributes/sub-objects that can't have roles.
Should they have to be protected by permissions? Probably...
If you need the sort of control that permissions provide, you should consider providing accessors that can play with permissions. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Okay, apologies in advance for picking up a thread that's been dorman for so long ;-) Jim Fulton wrote:
Chris Withers wrote:
self.id = id self.title = 'Title!' self.anInt = 0 self.aString = 'testing'
None of the values above can have a __roles__ attribute, so they are covered by assertions made in their containers.
That's what I thought....
Note that if you can't adequately control something that can't have __roles__, you can provide an access function (e.g. getAnInt), which you can control
Can I read them? I think the answer is yes for anInt and no for aString.
Probably, if you can get at one, you can get at the other.
That's not my experience. If you try and use strings, you get dialog boxes popping up. If you use ints, it works fine. So, the problem is how to protect ints when you don't want people to get at them... Adding accessors mean you have protected accessors bu there's nothing to stop you just going and using the freely available original attribute. Strings; fine, at least they're secure, and when they become proper objects in Python 2.0, the problem should go away? cheers, Chris
Chris Withers wrote:
Okay, apologies in advance for picking up a thread that's been dorman for so long ;-)
Jim Fulton wrote:
Chris Withers wrote:
self.id = id self.title = 'Title!' self.anInt = 0 self.aString = 'testing'
None of the values above can have a __roles__ attribute, so they are covered by assertions made in their containers.
That's what I thought....
Note that if you can't adequately control something that can't have __roles__, you can provide an access function (e.g. getAnInt), which you can control
Can I read them? I think the answer is yes for anInt and no for aString.
Probably, if you can get at one, you can get at the other.
That's not my experience.
There's something very odd going on. The issue isn't stringness or intness but role-less-ness. :)
If you try and use strings, you get dialog boxes popping up. If you use ints, it works fine.
I've never seen this.
So, the problem is how to protect ints when you don't want people to get at them... Adding accessors mean you have protected accessors bu there's nothing to stop you just going and using the freely available original attribute.
Yes there is. Access to attributes is controlled by the roles if their container. You should also be able to create specific unprotected attribute assertions using the mechanism described in: http://www.zope.org/Members/michel/Projects/Interfaces/ZopeSecurityPolicy I'll admit that I haven't tried this. If you try it soon (like today) and find it broken, we can fix it for Zope 2.2.3.
Strings; fine, at least they're secure, and when they become proper objects in Python 2.0, the problem should go away?
Will Python 2.0 let you assign string attributes? Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Jim Fulton wrote:
Strings; fine, at least they're secure, and when they become proper objects in Python 2.0, the problem should go away?
Will Python 2.0 let you assign string attributes?
% python Python 2.0 (#3, Oct 26 2000, 15:07:09) [GCC 2.95.2 19991024 (release)] on sunos5 Type "copyright", "credits" or "license" for more information.
a='' a.foo='bar' Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: object has read-only attributes
-- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
participants (5)
-
Brian Lloyd -
Chris Withers -
Jim Fulton -
Phillip J. Eby -
Steve Alexander