Re: [Zope-dev] More on [Removal of aq_acquire from guarded_getattr]

[Richard Jones]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 7 Feb 2005 05:26 pm, Richard Jones wrote:
> That is, there's no acquisition context on the simple string. To "fix" the
> problem, I changed secure_url to be a ComputedAttribute which looked up the
> instance attribute _secure_url. This then gave the value a valid
> acquisition chain and everything "works" now.

Please ignore this message. Everything does *not* work. I am at a loss as to 
why it worked *briefly*. Must've just been some other artifact introduced 
during the hours of messing with the code. Back to the code-mine.


Richard
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCBwrgrGisBEHG6TARAn57AJ9wnws/1GxZ7iMWUlqeWI8/8YNi9QCghqu9
pWtsieWTzWArDN1jZuam1L8=
=BwJH
-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] More on [Removal of aq_acquire from guarded_getattr]

[Richard Jones]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 25 Jan 2005 10:30 am, Stefan H. Holek wrote:
>- declaring object security on the acquiree via
> declareObjectProtected(foo)

For me, the problem arises when the acquiree is a Python builtin object - a 
string instance attribute in my case. Hence I can't make any useful statement 
like the above. I have a statement::

   security.setDefaultAccess({'secure_url': 1})

on the class, but with the change discussed here, that assertion is never 
looked up. I attempted to::

   security.declarePublic('secure_url') 

but of course that didn't change anything, as I mentioned the class assertions 
weren't being looked at.

After poking around some more, I realised that validate() 
(VerboseSecurityPolicy's) was being invoked with::

   aq_chain(container) = [
 ,
 ,
 ,
 ,
 ,
 ,
 ]

   context = 

   aq_chain(value) = ['http://secure.cgpublisher.localhost']

That is, there's no acquisition context on the simple string. To "fix" the 
problem, I changed secure_url to be a ComputedAttribute which looked up the 
instance attribute _secure_url. This then gave the value a valid acquisition 
chain and everything "works" now.

I'm really sorry I can't be more helpful and produce a useful test case, but 
I've a bazillion deadlines falling on the floor. Maybe in a few months. For 
now I just needed a work-around that will let me run in an un-patched Zope.


Richard
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCBwoerGisBEHG6TARAqRIAJwOOCtEccg2RqsjqjzlTLkEVfvn2gCeMYRw
qwFvrTuk5xxhYi0pAU+UcUo=
=SOlC
-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] More on [Removal of aq_acquire from guarded_getattr]

[Stefan H. Holek]

The failing AccessControl tests can now be found on shh-aqtests-branch 
in zope.org CVS.

Observations:
a) guarded_getattr checks object security of the acquiree if the 
container denies access (at least that's my assessment).

b) The tests pass when either
  - running Zope < 2.7.3, or
  - declaring object security on the acquiree via 
declareObjectProtected(foo)

c) Unauthorized errors pop up in CMF-based applications, typically when 
trying to access a portal tool from a Python Script. E.g. the tests for 
 fail on 1.4 branch because 
'portal_membership' can not be acquired.

d) Current Zope objects are ill-prepared for these checks as many do 
not bother to declare object security in the first place (User Folder, 
Mail Host, 50% of CMF tools, ...).

e) Plone and Archetypes exponentially increase the likelihood of 
encountering these errors. I have seen several variations in our 
customer projects, all reliably fixed by b)

f) I think this is serious. It certainly is a problem for Plone.
g) 


h) If g) really is THE fix for  all 
existing Zope software must be reviewed, IMO.

i) Unit tests + VerboseSecurity = useful.
Please advise,
Stefan
--
The time has come to start talking about whether the emperor is as well
dressed as we are supposed to think he is.   /Pete McBreen/
___
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 )