Hi,

...

I have protect my folder by using acl_users. But now I must allow access by anonymous to one DTML-Document. This document uses <dtml-in> to get data from my MySQL-Database. To allow acces I have to set the following security properties:

1. DTML-Document: View 2. Z-SQL-Method: Use Database Methods 3. Parent Folder: Access contents information

Is that right? 1 is for viewing HTML. 2 and 3 for access Database. I'm not realy sure, why I must set 3? Can somebody explain it?

It allows you to access the parent folder. Without it, you get an "Unauthorized" when you handle the parent folder in any way in an untrusted context.

But if I only have a DTML-Document without <dtml-in> only the security property DTML-Cokument.View is necessary. Is that correct? Thank, Patrick

Chris Withers wrote at 2005-2-10 10:31 +0000:

Patrick Ulmer wrote:

...

But if I only have a DTML-Document without <dtml-in> only the security property DTML-Cokument.View is necessary. Is that correct?

No, you need to actually be able to get to your dtml document in the first place. That means the user must somehow get the "Access contents information" permission on its container, and its container's container, and so on, up to the root of your Zope instance...

This would be the case, would ZPublisher use the standard traversal procedure. But, it fact, it does not do that. Instead, it traverses to the URL addressed target disregarding any security restrictions, determines which roles the target needs and than looks up again for a user folder that can authenticate a user with the necessary roles. Thus, the ZPublisher allows you to access objects despite the fact that you cannot access all ancestors of such an object. -- Dieter

Chris Withers wrote at 2005-2-11 11:59 +0000:

... Dieter Maurer wrote:

...

This would be the case, would ZPublisher use the standard traversal procedure. But, it fact, it does not do that. Instead, it traverses to the URL addressed target disregarding any security restrictions,

I'm afraid this is incorrect. ... Maybe you have some patches in place which affect this

In fact, I have patches in place -- but they do not change Zope in this way ;-)

, but a normal Zope server does not behave as you describe, and many people would be pretty disturbed if it did...

Then they should have a look at the code of "ZPublisher.BaseRequest.BaseRequest.traverse" This method is responsible for URL traversal. They can easily recognize two parts of this function: the traversal loop authentication During the traversal loop, there are no access checks (as I have said). And this must be the case, as there is not yet any user! "roles" are determined during traversal, usually for the last object traversed to, unless this object does not have a "__roles__" attribute (then for its parent, unless it does not have a "__roles__" attribute either, and so on). The authentication then looks for a userfolder that is able to authenticate a user with the roles determined during traversal. That's all of the security checks performed during traversal. In case, they are disturbed by this, then they have reasons indeed... Does the stock Zope code look differently ;-) -- Dieter

Chris Withers wrote at 2005-2-14 12:17 +0000:

Dieter Maurer wrote:

...

During the traversal loop, there are no access checks (as I have said). And this must be the case, as there is not yet any user!

Well, then please explain why a stock zope instance behaves as I described...

I do not take orders ;-) Look at the code and tell me where my description of it deviates from what you see... -- Dieter

Chris Withers wrote at 2005-2-15 09:39 +0000:

... Why don't you try following the steps I described, and then you can use your great intellect to explain why it behaves as it does, rather than as you say it should, or maybe tell me what I did wrong? ;-)

You did not look at the code ;-) -- Dieter

Hi Dieter, Dieter Maurer wrote:

When I remember right, you used a template to verify the behaviour you expect Zope to have.

But a standard template tries to access its client (in your setup the protected folder) to show its "title/id". And this fails, when the client does not grant "Access contents information" (in case "client" is a "Folder" as in your case).

I suggest, you try again with an "Image" object instead of a template or remove all references to "here" and "container" in your (Page) template.

Apologies, both you and Bart Hubbard, who pointed out the same reasoning, are completely correct. This feels like a pretty horrible security hole to me :-( What do other people think? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

Tres Seaver wrote:

This is *by design*, Chris:

Well, that may be, but what if the design is wrong? ;-)

it allows for "customers who have customers" to set up access to subsites, without requiring that users who can see the subsite to have *any* privileges at the layers above. In Unixy terms, this is like making the parent directories "a+x" (they can be traversed) without requiring that they be "a+r" (readable).

Okay, but what role-to-permissions mappings do you set so that no-one can access a particular object's contents, once they know its id? (ie: o-x)

FWIW, Zope3 allows this choice to be pluggable, because traversal is governed by view components, which are configured by default to check access.

Well, this does beg the question: is this how restrictedTraverse works? If not, then why isn't restrictedTraverse used? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

Chris McDonough wrote:

I never quite understood why this was the case (it is definitely confusing), but the fact that publisher traversal does not check each step has proven handy in situations where I've wanted to allow web access to deeply nested folders to people who don't actually have access to its parent folders.

Isn't that what the 'access contents information' permition is for? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

Dieter Maurer wrote:

I already answered this question (implicitly) in an earlier message:

ZPublisher cannot use "restrictedTraverse" because authentication happens only at the end of traversal.

Up to this point, there is no user and "restrictedTraverse" is likely to fail.

Okay, but maybe this should change? I know it's caused you problems in the past and resulted in having to implement a post-traversal hook/hack... There's still one remaining question: What role-to-permissions mappings do you set so that no-one can access a particular object's contents, once they know its id? (ie: o-x) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

Dieter Maurer wrote:

When you change it, you will loose user folders in subsites (which are quite essential).

Why? all you'd need to do is open up "access contents information" so anonymous users can traverse to the user folder...

...

What role-to-permissions mappings do you set so that no-one can access a particular object's contents, once they know its id?

In general, this is a very difficult questions.

* The concrete permission depends on the object type. It is the permission that is defined with "declareObjectProtected(...)".

Usually it is "Access contents information", but templates use "View" instead and other objects may choose to use a different permission.

* Even when the "object permission" is not granted, special methods (protected by whatever permission) may still be able to access an object's content.

Thus, you would need to revoke grants to such permissions as well.

Hmmm, a highly unsatisfactory answer :-( Not your fault Dieter, but I really feel there should be some obvious, simple way to say "no, you can't access anything in this folder or below unless you have permission X" cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

On 15.Feb 2005 - 09:39:19, Chris Withers wrote:

Dieter Maurer wrote:

...

...

Well, then please explain why a stock zope instance behaves as I described...

I do not take orders ;-)

Fine, then keep on handing out bogus information based on reading code rather than performing an empircal test.

He is right, the test on a stock zope using an image instead of a template allows me to access that image. I even have access if I only allow Anonymous to View the image.

...

Look at the code and tell me where my description of it deviates from what you see...

Why don't you try following the steps I described, and then you can use your great intellect to explain why it behaves as it does, rather than as you say it should, or maybe tell me what I did wrong? ;-)

You did wrong ;-) An empty PageTemplate (i.e. one that does not access it's parent or anything) can be viewed as Anonymous User by setting the View-Permission. Andreas -- This life is yours. Some of it was given to you; the rest, you made yourself.