Lately I've been noticing that http://host/zopeobject/manage_options is accessible TTW with no priveleges. Unless I'm on crack, wasn't always like this. I've been trying to figure out what changed and the only thing I can discern is is that may be related to using python 2.2. I've seen it happen with 2.6.1 & python 2.2, and I've seen it happen with HEAD & python 2.2, but never 2.6.1 & python 2.1.3. Can anyone else corroborate this? Even better does anyone else know how to fix it? I'm wondering if there's more hanging out in the open than just some attributes here and there. -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz
Jamie Heilman wrote:
Lately I've been noticing that http://host/zopeobject/manage_options is accessible TTW with no priveleges. Unless I'm on crack, wasn't always like this. I've been trying to figure out what changed and the only thing I can discern is is that may be related to using python 2.2. I've seen it happen with 2.6.1 & python 2.2, and I've seen it happen with HEAD & python 2.2, but never 2.6.1 & python 2.1.3. Can anyone else corroborate this? Even better does anyone else know how to fix it? I'm wondering if there's more hanging out in the open than just some attributes here and there.
You've uncovered an important difference between Python 2.1 and Python 2.2. Built-in objects now have docstrings. That means Zope running on Python 2.2 currently reveals a lot more TTW than Python 2.1 did. It's a good thing we haven't make Python 2.2 support official yet. (Python 2.1.3)
().__doc__ Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'tuple' object has no attribute '__doc__'
(Python 2.2.2)
().__doc__ "tuple() -> an empty tuple\ntuple(sequence) -> tuple initialized from sequence's items\n\nIf the argument is a tuple, the return value is the same object."
The same thing changed for integers and strings (and probably all other built-in types). The __doc__ check has always been hackish anyway. Ideas? Shane
On Mon, May 19, 2003 at 12:34:44PM -0400, Shane Hathaway wrote:
The same thing changed for integers and strings (and probably all other built-in types). The __doc__ check has always been hackish anyway. Ideas?
start declaring security on stuff that's traditionally relied on having no docstring? i know, big job :-( A quick bit of grepping turns up 59 .py files that do something with manage_options, and a quick browse of some of the results suggests that manage_options is typically a class-level tuple with no security declarations. which of course makes me wonder what else, besides manage_options, typically lacks security declarations... alternatively (I really really hate to suggest this) we could add some checks to BaseRequest.traverse() such that built-in types are not publishable. I hate to suggest it because: 1) traverse is already 266 lines long! 2) it could sometimes be really handy to have trivial publishable attributes that are built-in types, either for inspecting the state of an object via a browser or for RAD development of an app in the REST style (Representational State Transfer - see http://webservices.xml.com/pub/a/ws/2002/02/06/rest.html for an intro). I could imagine implementing something like: class BoxOfTools(SimpleItem): ... security.declarePublic('hammers') hammers = 0 security.declarePublic('screwdrivers') screwdrivers = 0 ... def __init__(self, ... hammers, screwdrivers): self.hammer = hammers self.screwdrivers = screwdrivers # code to handle PUT goes here Now an app using my server can visit http://server:8080/MyToolboxInstance/hammers to find out how many hammers the instance at that URL has, and can use http PUT to modify the instance. Neat way to work, and without built-in types being publishable it's just a bit more work: ... security.declarePublic('hammers') def hammers(self): """get the hammer count""" return str(self._hammers) ... Admittedly this is a pretty small difference, and a silly example, but there's something really appealing about the simplicity of the first example. -- Paul Winkler home: http://www.slinkp.com "Muppet Labs, where the future is made - today!"
Paul Winkler wrote:
On Mon, May 19, 2003 at 12:34:44PM -0400, Shane Hathaway wrote:
The same thing changed for integers and strings (and probably all other built-in types). The __doc__ check has always been hackish anyway. Ideas?
start declaring security on stuff that's traditionally relied on having no docstring?
We can't, unless we overhaul the security policy. Declarations for built-in types get ignored. This is because the security policy depends on being able to find a __roles__ attribute on the thing accessed. Instances of built-in types do not allow extra attributes (nor should they.) So, for example, declarePrivate('some_string_attribute') has no effect, nor did it ever have any effect. It's a nasty situation. :-( But overhauling the security policy is probably too big a change for making Zope 2.6 compatible with Python 2.2. Ironically, the new docstrings are wrong. ().__doc__ gives you information about how to construct a tuple instead of telling you how to use the tuple you've already created. So we could lobby PythonLabs to fix the docstrings, but that wouldn't solve Zope's problem.
alternatively (I really really hate to suggest this) we could add some checks to BaseRequest.traverse() such that built-in types are not publishable. I hate to suggest it because:
1) traverse is already 266 lines long!
Even so, we might have to do something like this. As another option, I wonder how well it would work to refuse to publish anything that has no __roles__ attribute... or some variation on that.
2) it could sometimes be really handy to have trivial publishable attributes that are built-in types, either for inspecting the state of an object via a browser or for RAD development of an app in the REST style (Representational State Transfer - see http://webservices.xml.com/pub/a/ws/2002/02/06/rest.html for an intro). I could imagine implementing something like:
Zope 2.6 + Python 2.1 tries to disallow access to simple attributes because of the number of things it would let you access that you couldn't before. Yes, it would be useful, but we need Zope 2.6 + Python 2.2 to act the same as Zope 2.6 + Python 2.1.
Admittedly this is a pretty small difference, and a silly example, but there's something really appealing about the simplicity of the first example.
You're going to enjoy Zope 3. ;-) Shane
On Mon, May 19, 2003 at 03:54:44PM -0400, Shane Hathaway wrote:
Paul Winkler wrote:
start declaring security on stuff that's traditionally relied on having no docstring?
We can't, unless we overhaul the security policy. Declarations for built-in types get ignored. This is because the security policy depends on being able to find a __roles__ attribute on the thing accessed.
ack! ok then, never mind :)
Even so, we might have to do something like this. As another option, I wonder how well it would work to refuse to publish anything that has no __roles__ attribute... or some variation on that.
given what you've just told me, that's the obvious solution.
Zope 2.6 + Python 2.1 tries to disallow access to simple attributes because of the number of things it would let you access that you couldn't before. Yes, it would be useful, but we need Zope 2.6 + Python 2.2 to act the same as Zope 2.6 + Python 2.1.
we do? I thought 2.6 + 2.2 was going to be permanently "not recommended", and 2.7 + 2.2 was going to be the future.
You're going to enjoy Zope 3. ;-)
i know, wish i had time to play with it :( -- Paul Winkler home: http://www.slinkp.com "Muppet Labs, where the future is made - today!"
Paul Winkler wrote:
On Mon, May 19, 2003 at 03:54:44PM -0400, Shane Hathaway wrote:
Zope 2.6 + Python 2.1 tries to disallow access to simple attributes because of the number of things it would let you access that you couldn't before. Yes, it would be useful, but we need Zope 2.6 + Python 2.2 to act the same as Zope 2.6 + Python 2.1.
we do? I thought 2.6 + 2.2 was going to be permanently "not recommended", and 2.7 + 2.2 was going to be the future.
The plan has changed. We plan to make a future release of Zope 2.6 that runs on both Python 2.1 and Python 2.2. Zope 2.7 will require Python 2.2. Shane
Shane Hathaway wrote at 2003-5-19 15:54 -0400:
... We can't, unless we overhaul the security policy. Declarations for built-in types get ignored. This is because the security policy depends on being able to find a __roles__ attribute on the thing accessed. Instances of built-in types do not allow extra attributes (nor should they.) So, for example, declarePrivate('some_string_attribute') has no effect, nor did it ever have any effect.
I do not think so (at least when I understand the code correctly). When the object does not have a "__roles__" attribute, its container is checked. Place the security declaration there (e.g. coded in the form "<attribute>__roles__") for objects that can not carry it themselves. Dieter
Instances of built-in types do not allow extra attributes (nor should they.) So, for example, declarePrivate('some_string_attribute') has no effect, nor did it ever have any effect.
We don't need instances of built-in types to allow extra attributes. So, no need to say {}.__roles__ = something. What we would need is to be able to say dict.__roles__ = something. It would be nice if the objects that represent built-in types could have attributes set on them. This would be helpful for some things in Zope 3 too. -- Steve Alexander
On Wed, May 21, 2003 at 06:47:31PM +0300, Steve Alexander wrote:
Instances of built-in types do not allow extra attributes (nor should they.) So, for example, declarePrivate('some_string_attribute') has no effect, nor did it ever have any effect.
We don't need instances of built-in types to allow extra attributes. So, no need to say {}.__roles__ = something. What we would need is to be able to say dict.__roles__ = something.
but then all instances would have the same roles.
It would be nice if the objects that represent built-in types could have attributes set on them. This would be helpful for some things in Zope 3 too.
I dunno. I'm starting to come around and think that it's not that big of a deal. One could always just have a publishableDict that subclasses dict. -- Paul Winkler home: http://www.slinkp.com "Muppet Labs, where the future is made - today!"
Steve Alexander wrote:
Instances of built-in types do not allow extra attributes (nor should they.) So, for example, declarePrivate('some_string_attribute') has no effect, nor did it ever have any effect.
We don't need instances of built-in types to allow extra attributes. So, no need to say {}.__roles__ = something. What we would need is to be able to say dict.__roles__ = something.
It would be nice if the objects that represent built-in types could have attributes set on them. This would be helpful for some things in Zope 3 too.
Actually, a piece of only moderately evil C code could do this. In Python 2.2, tuple.__dict__ is a dict-proxy object. This is a dict-like object that presents a read-only interface to a regular python dict. The struct of a dictproxy is not exported. However, one could abuse tp_traverse with an appropriate visiter function to set an item in the dict using only the exported C API. -- Steve Alexander
We don't need instances of built-in types to allow extra attributes. So, no need to say {}.__roles__ = something. What we would need is to be able to say dict.__roles__ = something.
It would be nice if the objects that represent built-in types could have attributes set on them. This would be helpful for some things in Zope 3 too.
There are important reasons why I don't want this, and in fact will go to great lengths to prevent this. Reason 1: multiple interpreters share the built-in type objects, and modifying a built-in type will affect all interpreters. Reason 2: if this were allowed, people *will* abuse it to change the behavior of built-in types to suit their purposes, and then they will be disappointed when they break standard library stuff that they don't realize they need. So better put a stop to that. --Guido van Rossum (home page: http://www.python.org/~guido/)
Shane Hathaway wrote:
You've uncovered an important difference between Python 2.1 and Python 2.2. Built-in objects now have docstrings. That means Zope running on Python 2.2 currently reveals a lot more TTW than Python 2.1 did. It's a good thing we haven't make Python 2.2 support official yet.
Of course! I should have thought of that. OK, well, hrm. How does Zope 3 deliniate between public, private, protected, and publishable? Any chance we can backport its "feel" if not its actual mechanism? -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz
Shane Hathaway wrote at 2003-5-19 12:34 -0400:
The same thing changed for integers and strings (and probably all other built-in types). The __doc__ check has always been hackish anyway. Ideas?
In the long term, we probably want an explicit declaration allowing ZPublisher publication. Probably, togother with a script that can parse Python module files and add the declaration for methods with a doc string. In the short term, ZPublisher could check for elementary data types and refuse to publish them. Dieter
participants (6)
-
Dieter Maurer -
Guido van Rossum -
Jamie Heilman -
Paul Winkler -
Shane Hathaway -
Steve Alexander