Re: [Zope-dev] Re: ZCatalog getObject broken

[Chris Withers]

Florent Guillaume wrote:
Ah, okay, I thought that's what you meant, but I hoped it wasn't.
The fact that you expect this to work is a bug in Zope's security 
machinery, IMHO, but sadly only IMHO it appears.
Huh? That's fundamental to Zope's security model.
As I said, I appear to be the only person who thinks differently. I 
don't believe it's fundamental to Zope's security policy myself, and I 
think Zope would be just fine and less suprising to those of us who 
value security if it all behaved like restrictedTraverse...

Well, you must be the only one who never had a need for security
restrictions elsewhere than at the root of the site.
I understand the pros and cons, don't worry ;-)
Chris
--
Simplistix - Content Management, Zope & Python Consulting
   - http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: ZCatalog getObject broken

[Florent Guillaume]

Chris Withers  <[EMAIL PROTECTED]> wrote:
> > A, B and C are folders nested in each other i.e. A/B/C. A user does not
> > have access to A and B but he does have access to C. If getObject uses
> > restrictedTraverse it returns None immediately when traversing A, even
> > though the user is allowed to access C. If getObject was working
> > properly it would have returned C.
> 
> Ah, okay, I thought that's what you meant, but I hoped it wasn't.
> The fact that you expect this to work is a bug in Zope's security 
> machinery, IMHO, but sadly only IMHO it appears.

Huh? That's fundamental to Zope's security model.

> I would have no problem with the above behaviour if getObject raised 
> Unauthorized rather than returned None.
> 
> Your patch still had it returning None, IIRC, why did it do that?
> 
> > The rest of the discussion basically boils down to figure out if the
> > user is allowed to access C or not.
> 
> Yep, personally I reckon EVRYTHING should behave like 
> restrictedTraverse, but as I said, that appears to just be me...

Well, you must be the only one who never had a need for security
restrictions elsewhere than at the root of the site.

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: ZCatalog getObject broken

[Chris Withers]

Roché Compaan wrote:
This is what I am arguing but I haven't had anybody agree/disagree with
me yet. It is also a lot simpler to fix:
< return self.aq_parent.restrictedTraverse(self.getPath(), None)
---
   return self.aq_parent.unrestrictedTraverse(self.getPath(), None)
I don't really mind either, provided the ,None vanishes...
Chris
--
Simplistix - Content Management, Zope & Python Consulting
   - http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: ZCatalog getObject broken

[Chris Withers]

Roché Compaan wrote:
I don't get why you're not getting it :-)
A, B and C are folders nested in each other i.e. A/B/C. A user does not
have access to A and B but he does have access to C. If getObject uses
restrictedTraverse it returns None immediately when traversing A, even
though the user is allowed to access C. If getObject was working
properly it would have returned C.
Ah, okay, I thought that's what you meant, but I hoped it wasn't.
The fact that you expect this to work is a bug in Zope's security 
machinery, IMHO, but sadly only IMHO it appears.
I would have no problem with the above behaviour if getObject raised 
Unauthorized rather than returned None.

Your patch still had it returning None, IIRC, why did it do that?
The rest of the discussion basically boils down to figure out if the
user is allowed to access C or not.
Yep, personally I reckon EVRYTHING should behave like 
restrictedTraverse, but as I said, that appears to just be me...

Chris
--
Simplistix - Content Management, Zope & Python Consulting
   - http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: ZCatalog getObject broken

[Dieter Maurer]

Max M wrote at 2005-3-11 19:10 +0100:
> ...
>A single method might be public, but the rest of the object is hidden.
>
>What to do then? Just ignore the public method and use the objects 
>overall visibility?

The object has a "ObjectPermission" that controls handling references (!)
to the object (itself) in TTW code.
TTW code should not get a reference to an object when it does
not have the "ObjectPermission" on it.

Therefore, "getObject" tries hard to return "None" instead of the
object in these cases.

-- 
Dieter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: ZCatalog getObject broken

[Roché Compaan]

On Fri, 2005-03-11 at 19:10 +0100, Max M wrote:
> Roché Compaan wrote:
> 
> > The rest of the discussion basically boils down to figure out if the
> > user is allowed to access C or not.
> 
> Hasn't it been raised allready that there is no way of knowing that?
> 
> A single method might be public, but the rest of the object is hidden.

This is what I am arguing but I haven't had anybody agree/disagree with
me yet. It is also a lot simpler to fix:

< return self.aq_parent.restrictedTraverse(self.getPath(), None)
---
> return self.aq_parent.unrestrictedTraverse(self.getPath(), None)


-- 
Roché Compaan
Upfront Systems   http://www.upfrontsystems.co.za

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: ZCatalog getObject broken

[Max M]

Roché Compaan wrote:
The rest of the discussion basically boils down to figure out if the
user is allowed to access C or not.
Hasn't it been raised allready that there is no way of knowing that?
A single method might be public, but the rest of the object is hidden.
What to do then? Just ignore the public method and use the objects 
overall visibility?

--
hilsen/regards Max M, Denmark
http://www.mxm.dk/
IT's Mad Science
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: ZCatalog getObject broken

[Roché Compaan]

On Fri, 2005-03-11 at 15:47 +, Chris Withers wrote:
> Florent Guillaume wrote:
> > In the current getObject problem that concerns us, we want to do better
> > that restrictedTraverse,
> 
> Why? As far as any problems I had go, it was purely the "returning None 
> when the user can see the object" that was the bug. Provided getObject 
> raises unauthorised when a user isn't allowe to see something, that 
> works for me.
> 
> Now, I'm obiously missing something, so what is the problem that you and 
> Roché are having?

I don't get why you're not getting it :-)

A, B and C are folders nested in each other i.e. A/B/C. A user does not
have access to A and B but he does have access to C. If getObject uses
restrictedTraverse it returns None immediately when traversing A, even
though the user is allowed to access C. If getObject was working
properly it would have returned C.

The rest of the discussion basically boils down to figure out if the
user is allowed to access C or not.

-- 
Roché Compaan
Upfront Systems   http://www.upfrontsystems.co.za

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: ZCatalog getObject broken

[Chris Withers]

Florent Guillaume wrote:
In the current getObject problem that concerns us, we want to do better
that restrictedTraverse,
Why? As far as any problems I had go, it was purely the "returning None 
when the user can see the object" that was the bug. Provided getObject 
raises unauthorised when a user isn't allowe to see something, that 
works for me.

Now, I'm obiously missing something, so what is the problem that you and 
Roché are having?

Chris
--
Simplistix - Content Management, Zope & Python Consulting
   - http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: ZCatalog getObject broken

[Florent Guillaume]

Tres Seaver  <[EMAIL PROTECTED]> wrote:
> Chris McDonough wrote:
> | I implemented a "publisherTraverse" function like this FWIW:
> |
> | def publisherTraverse(context, path):
> | # this is a hack to get around the fact that restrictedTraverse,
> | # unlike publisher traversal, does checks at every step of the
> | # path.  We don't want to limit access in this way (e.g. nested
> | # shares are possible) so we reimplement restrictedTraverse in a
> | # way that that emulates publisher traversal semantics
> | ob = context.unrestrictedTraverse(path)
> | user = getSecurityManager().getUser()
> | if not user.has_permission('View', ob):
> | raise zExceptions_Unauthorized, "cant traverse to %s" % path
> | return ob
> 
> I don't think that the 'has_permission' check is quite right:  at least,
> that isn't what the publisher does.  'ZPublisher.BaseRequest.traverse'
> collects roles during the traversal, and then calls the user folder's
> 'validate', passing them at the end.  Note as well that 'View' may not
> be the permission which is protecting the traversed-to object).
> 
> The "correct" emulation would probably be to call the user object's
> 'authorize' method, passing the proper values for accessed, container,
> name, value, and roles.  Figuring out the proper values is left as an
> exercise for the reader ;).

Yeah that's what I'm digging through right now :-( The publisher's
collecting of the correct __roles__ from the intermediate traversed
objects is quite complex. Also validation (actually trying to get a user
that has access) tries user folders above if it fails. A correct
publisherTraverse (which is also a method I'd like to have) is *much*
more complex than what's shown above. And BTW the traverse() method
should be shot in the head.

In the current getObject problem that concerns us, we want to do better
that restrictedTraverse, but maybe trying to emulate the full publisher
rules is overly complex.

>From what I see traverse():

1. does validation checks by actually trying to authenticate a user,
   which is done according to its credentials and from the context
   of the published object, and retried with above user folders if
   no user is found on the first one,
2. also checks for potential __roles__ found:
   - on an intermediate objects gotten by __bobo_traverse__,
   - if the published object has a __call__.__roles__.

OTOH restrictedTraverse on each step:

1. does its validation using the current security manager's validate(),
2. does not collect any roles, so validate() uses its default behavior
   which ends up basically doing aq_acquire('__roles__').

So in a first pass that should be enough to fix our common problem, I
propose to just do basically what Dieter mentionned:
- unrestrictedTraverse to the parent
- restrictedTraverse for the final step

(I'll be testing this of course.)

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: ZCatalog getObject broken

[Dieter Maurer]

Chris McDonough wrote at 2005-3-10 11:28 -0500:
>I implemented a "publisherTraverse" function like this FWIW:
>
>def publisherTraverse(context, path):
># this is a hack to get around the fact that restrictedTraverse,
># unlike publisher traversal, does checks at every step of the
># path.  We don't want to limit access in this way (e.g. nested
># shares are possible) so we reimplement restrictedTraverse in a
># way that that emulates publisher traversal semantics
>ob = context.unrestrictedTraverse(path)
>user = getSecurityManager().getUser()
>if not user.has_permission('View', ob):
>raise zExceptions_Unauthorized, "cant traverse to %s" % path
>return ob
>
>Maybe this is better than using validate?

No, because it does not take executable permission context
into account (e.g. proxy roles).

-- 
Dieter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: ZCatalog getObject broken

[Roché Compaan]

On Thu, 2005-03-10 at 12:13 -0500, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Chris McDonough wrote:
> | I implemented a "publisherTraverse" function like this FWIW:
> |
> | def publisherTraverse(context, path):
> | # this is a hack to get around the fact that restrictedTraverse,
> | # unlike publisher traversal, does checks at every step of the
> | # path.  We don't want to limit access in this way (e.g. nested
> | # shares are possible) so we reimplement restrictedTraverse in a
> | # way that that emulates publisher traversal semantics
> | ob = context.unrestrictedTraverse(path)
> | user = getSecurityManager().getUser()
> | if not user.has_permission('View', ob):
> | raise zExceptions_Unauthorized, "cant traverse to %s" % path
> | return ob
> 
> I don't think that the 'has_permission' check is quite right:  at least,
> that isn't what the publisher does.  'ZPublisher.BaseRequest.traverse'
> collects roles during the traversal, and then calls the user folder's
> 'validate', passing them at the end.  Note as well that 'View' may not
> be the permission which is protecting the traversed-to object).
> 
> The "correct" emulation would probably be to call the user object's
> 'authorize' method, passing the proper values for accessed, container,
> name, value, and roles.  Figuring out the proper values is left as an
> exercise for the reader ;).

Is it at all possible to figure out the proper values? Earlier in this
thread I asked if it is clear what value should be validated? It seems
to me that returning None when the user does not have access to the
object, imposes the same illogical constraint that the current
implementation does, in that it does not allow access to a method or
attribute of that object that is guarded less. One cannot predict when
calling getObject what method or attribute the user wants to access.

If it is possible to have access to a single method of the object but
nothing else of that object, then it doesn't make sense to do *any*
security checks in getObject. The object's own security assertions
should guard access to its attributes.


-- 
Roché Compaan
Upfront Systems   http://www.upfrontsystems.co.za

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: ZCatalog getObject broken

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris McDonough wrote:
| I implemented a "publisherTraverse" function like this FWIW:
|
| def publisherTraverse(context, path):
| # this is a hack to get around the fact that restrictedTraverse,
| # unlike publisher traversal, does checks at every step of the
| # path.  We don't want to limit access in this way (e.g. nested
| # shares are possible) so we reimplement restrictedTraverse in a
| # way that that emulates publisher traversal semantics
| ob = context.unrestrictedTraverse(path)
| user = getSecurityManager().getUser()
| if not user.has_permission('View', ob):
| raise zExceptions_Unauthorized, "cant traverse to %s" % path
| return ob
I don't think that the 'has_permission' check is quite right:  at least,
that isn't what the publisher does.  'ZPublisher.BaseRequest.traverse'
collects roles during the traversal, and then calls the user folder's
'validate', passing them at the end.  Note as well that 'View' may not
be the permission which is protecting the traversed-to object).
The "correct" emulation would probably be to call the user object's
'authorize' method, passing the proper values for accessed, container,
name, value, and roles.  Figuring out the proper values is left as an
exercise for the reader ;).
Oracular'ly,
Tres.
- --
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation  "Zope Dealers"   http://www.zope.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCMIAxGqWXf00rNCgRAicEAJ4xoSRVeFBDNGixfenZsXK58aN/zACfUbFF
SNfOYkCwgZyV30fl1H3ttko=
=rdT7
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: ZCatalog getObject broken

[Chris McDonough]

I implemented a "publisherTraverse" function like this FWIW:

def publisherTraverse(context, path):
# this is a hack to get around the fact that restrictedTraverse,
# unlike publisher traversal, does checks at every step of the
# path.  We don't want to limit access in this way (e.g. nested
# shares are possible) so we reimplement restrictedTraverse in a
# way that that emulates publisher traversal semantics
ob = context.unrestrictedTraverse(path)
user = getSecurityManager().getUser()
if not user.has_permission('View', ob):
raise zExceptions_Unauthorized, "cant traverse to %s" % path
return ob

Maybe this is better than using validate?

On Thu, 2005-03-10 at 11:06, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Florent Guillaume wrote:
> | Dieter Maurer  <[EMAIL PROTECTED]> wrote:
> |
> |>Rochà Compaan wrote at 2005-2-25 17:22 +0200:
> |>
> |>> Last year in March the following checkin was made that changed
> |>> ZCatalog's getObject to use restrictedTraverse instead of
> |>> unrestrictedTraverse. See:
> |>>
> |>>http://mail.zope.org/pipermail/zope-checkins/2004-March/026846.html
> |>>
> |>>In my opininion this is wrong,
> |>
> |>I agree with you!
> |
> |
> | Me also.
> |
> |
> |>>...
> |>> I would propose that getObject does an unrestrictedTraverse of
> |>> the path and then checks if the user has permission to access
> |>> that the object.
> |>
> |> I argued precisely this approach with the person who made the
> |> change. I had the impression that I have convinced him -- but
> |> apparently, he did not change the code accordingly :-(
> |>
> |>Maybe, a bug report to the collector will help?
> |>
> |>   
> |
> |
> | Rochà has added http://www.zope.org/Collectors/Zope/1713
> |
> | I intend to fix this before 2.7.5 final, probably today or tonight. I
> | feel this is sufficiently important to warrant a fix now. I guess
> | it'll mean an RC2.
> |
> | Please shout if you find problems with this approach.
> 
> Please note that calling 'validate' without passing the correct values
> for 'container', 'accessed', and 'name' may lead to unexpected results
> (it tries to guess, but may not be clever enough, especially if there is
> any weird wrapping / unwrapping in play).  This was essentially the
> issue which led to the "spurious Unauthorized error" problem in Zope
> 2.7.3 (this point is germane or issue #1534, as well as #1713).
> 
> Tres.
> - --
> ===
> Tres Seaver[EMAIL PROTECTED]
> Zope Corporation  "Zope Dealers"   http://www.zope.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.4 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFCMHBnGqWXf00rNCgRAvVZAJ9vlruC2X6Q60g8kzYpbcy8Rk8E/ACdGktW
> 4rPMryTLyixAABvKf/tj184=
> =U7gY
> -END PGP SIGNATURE-
> 
> ___
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )
> 

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: ZCatalog getObject broken

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Florent Guillaume wrote:
| Dieter Maurer  <[EMAIL PROTECTED]> wrote:
|
|>Roché Compaan wrote at 2005-2-25 17:22 +0200:
|>
|>> Last year in March the following checkin was made that changed
|>> ZCatalog's getObject to use restrictedTraverse instead of
|>> unrestrictedTraverse. See:
|>>
|>>http://mail.zope.org/pipermail/zope-checkins/2004-March/026846.html
|>>
|>>In my opininion this is wrong,
|>
|>I agree with you!
|
|
| Me also.
|
|
|>>...
|>> I would propose that getObject does an unrestrictedTraverse of
|>> the path and then checks if the user has permission to access
|>> that the object.
|>
|> I argued precisely this approach with the person who made the
|> change. I had the impression that I have convinced him -- but
|> apparently, he did not change the code accordingly :-(
|>
|>Maybe, a bug report to the collector will help?
|>
|>   
|
|
| Roché has added http://www.zope.org/Collectors/Zope/1713
|
| I intend to fix this before 2.7.5 final, probably today or tonight. I
| feel this is sufficiently important to warrant a fix now. I guess
| it'll mean an RC2.
|
| Please shout if you find problems with this approach.
Please note that calling 'validate' without passing the correct values
for 'container', 'accessed', and 'name' may lead to unexpected results
(it tries to guess, but may not be clever enough, especially if there is
any weird wrapping / unwrapping in play).  This was essentially the
issue which led to the "spurious Unauthorized error" problem in Zope
2.7.3 (this point is germane or issue #1534, as well as #1713).
Tres.
- --
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation  "Zope Dealers"   http://www.zope.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCMHBnGqWXf00rNCgRAvVZAJ9vlruC2X6Q60g8kzYpbcy8Rk8E/ACdGktW
4rPMryTLyixAABvKf/tj184=
=U7gY
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: ZCatalog getObject broken

[Roché Compaan]

On Thu, 2005-03-03 at 09:27 +0100, Max M wrote:
> Roché Compaan wrote:
> 
> > I'm unsure about the security check in the patch below - I copied the
> > way restrictedTraverse does it. I read through validate in the default
> > security policy but it is one of those methods where all the security
> > implications doesn't fit in your head all at once.
> > 
> > --- CatalogBrains.py~   2004-03-23 22:27:23.0 +0200
> > +++ CatalogBrains.py2005-03-03 09:43:48.0 +0200
> > @@ -47,7 +47,11 @@
> >  (i.e., it was deleted or moved without recataloging), or if the
> > user is
> >  not authorized to access an object along the path.
> >  """
> > -return self.aq_parent.restrictedTraverse(self.getPath(), None)
> > +obj = self.aq_parent.unrestrictedTraverse(self.getPath(), None)
> > +if obj and securityManager.validate(obj, obj, None, None):
> > +return obj
> > +else:
> > +return None
> 
> 
> There is a method deep down in Zope somewhere called:
> 
> self.authenticated_has_access(obj)
> 
> I cannot find the definition on my local Windows install, so I assume 
> it's defined in some c code somewhere.
> 
> Unfortunately there is no docs on the web either. Though there must have 
> been at some time, as I would otherwise never have found it.
> 
> Hmm... that is odd.
> 

In this context the user does not need to be authenticated - Anonymous
might have view rights in the context of the object.

-- 
Roché Compaan
Upfront Systems http://www.upfrontsystems.co.za

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: ZCatalog getObject broken

[Max M]

Roché Compaan wrote:
I'm unsure about the security check in the patch below - I copied the
way restrictedTraverse does it. I read through validate in the default
security policy but it is one of those methods where all the security
implications doesn't fit in your head all at once.
--- CatalogBrains.py~   2004-03-23 22:27:23.0 +0200
+++ CatalogBrains.py2005-03-03 09:43:48.0 +0200
@@ -47,7 +47,11 @@
 (i.e., it was deleted or moved without recataloging), or if the
user is
 not authorized to access an object along the path.
 """
-return self.aq_parent.restrictedTraverse(self.getPath(), None)
+obj = self.aq_parent.unrestrictedTraverse(self.getPath(), None)
+if obj and securityManager.validate(obj, obj, None, None):
+return obj
+else:
+return None

There is a method deep down in Zope somewhere called:
self.authenticated_has_access(obj)
I cannot find the definition on my local Windows install, so I assume 
it's defined in some c code somewhere.

Unfortunately there is no docs on the web either. Though there must have 
been at some time, as I would otherwise never have found it.

Hmm... that is odd.
--
hilsen/regards Max M, Denmark
http://www.mxm.dk/
IT's Mad Science
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: ZCatalog getObject broken

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andreas Jung wrote:
|
|
| --On Freitag, 25. Februar 2005 20:21 Uhr +0100 Dieter Maurer
| <[EMAIL PROTECTED]> wrote:
|
|> Roché Compaan wrote at 2005-2-25 17:22 +0200:
|>
|>> Last year in March the following checkin was made that changed
|>> ZCatalog's getObject to use restrictedTraverse instead of
|>> unrestrictedTraverse. See:
|>>
|>> http://mail.zope.org/pipermail/zope-checkins/2004-March/026846.html
|>>
|>> In my opininion this is wrong,
|>
|>
|> I agree with you!
|>
|>> ...
|>> I would propose that getObject does an unrestrictedTraverse of the path
|>> and then checks if the user has permission to access that the object.
|>
|>
|> I argued precisely this approach with the person who made the
|> change. I had the impression that I have convinced him -- but
|> apparently, he did not change the code accordingly :-(
|>
|> Maybe, a bug report to the collector will help?
|>
|>
|>
|
| Best to include a patch as well :-)
And a new test which fails under the current code, but succeeds with the
patch. ;)
Tres.
- --
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation  "Zope Dealers"   http://www.zope.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCH50UGqWXf00rNCgRAradAJ9/v/nU3iZEALYK+7hI2NYZCZbi0ACggAxm
l4LfqI3+RYCI8VRHV9cz0rU=
=4SWg
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )