[Zope-dev] Bugs in new Security Stuff :P (part1)

2000-08-22 Thread Chris Withers

Right, firstup this thing about HTMLFile's which form part of the
management interface. 

Why are they totally immune to the security stuff? It gets really
confusing when something works fine in a management screen and yet
breaks everywhere else, especially when it's not throwing a security
error (more in part II ;-)

So, why is it like this?

cheers,

Chris

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




Re: [Zope-dev] aq_inContextOf/can anyone explain this zmonitor log?

2000-08-22 Thread Bob Pepin

On Mon, Aug 21, 2000 at 04:21:33PM +0100, Toby Dickenson wrote:
 On Mon, 21 Aug 2000 16:03:38 +0200, Bob Pepin [EMAIL PROTECTED] wrote:
 
 Yeah, this is a good one. Theres some debate in the Collector about
 whether this is actually a bug or not.
 
 In short, aq_inContextOf checks for nested aquisition contexts. It
 does *not* check for nested objects.  It will return zero if you pass
 it parallel acquisition contexts, even if the objects are indeed
 nested.
 Here is the full story, and a patch to get it to work the other way.
 
 http://classic.zope.org:8080/Collector/1066/view
 
 (This patch used to work, but ive not used it since it was submitted)

hmm... shouldn't either User.BasicUser.allowed() or aq_inContextOf be modified
then, since the intent in allowed() doesn't seem to be to check for nested
contexts?

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




Re: [Zope-dev] Bugs in new Security Stuff :P (part1)

2000-08-22 Thread R. David Murray

On Tue, 22 Aug 2000, Chris Withers wrote:
 Why are they totally immune to the security stuff? It gets really
 confusing when something works fine in a management screen and yet
 breaks everywhere else, especially when it's not throwing a security
 error (more in part II ;-)
 
 So, why is it like this?

My guess:  because part of the Zope security model is that if you
have access to the file system (ie: external method, python product)
you are allowed to do anything.  It's only when you try to call
that anything from dtml that security gets involved (unless you
code the security yourself).

Under the new security model of "denied unless explicitly permitted",
the current behavior of on-disk dtml methods is arguably wrong.

--RDM


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




[Zope-dev] Security Stuff :P (part 3) : the tracebacks

2000-08-22 Thread Chris Withers

Well, what do you know? I leave it for a couple fo hours to set up a
laptop, come back and try again.
It's not hanging anymore, but I'm still getting the errors when I click
cancel:

Chris Withers wrote:
 Posting's objects have a text attribute called 'subject'
 
 Unless you have __allow_access_to_unprotected_subobjects__=1, you get
 the following error after you hit cancel on the authentication dialog
 box that pops up:

Traceback (innermost last):
  File E:\Zope\227194~1.0\lib\python\ZPublisher\Publish.py, line 222, in
publish_module
  File E:\Zope\227194~1.0\lib\python\ZPublisher\Publish.py, line 187, in
publish
  File E:\Zope\227194~1.0\lib\python\ZPublisher\Publish.py, line 171, in
publish
  File E:\Zope\227194~1.0\lib\python\ZPublisher\mapply.py, line 160, in
mapply
(Object: index_html)
  File E:\Zope\227194~1.0\lib\python\ZPublisher\Publish.py, line 112, in
call_object
(Object: index_html)
  File E:\Zope\227194~1.0\lib\python\OFS\DTMLMethod.py, line 167, in
__call__
(Object: index_html)
  File E:\Zope\227194~1.0\lib\python\DocumentTemplate\DT_String.py, line
502, in __call__
(Object: index_html)
  File E:\Zope\227194~1.0\lib\python\OFS\DTMLMethod.py, line 163, in
__call__
(Object: site_header)
  File E:\Zope\227194~1.0\lib\python\DocumentTemplate\DT_String.py, line
502, in __call__
(Object: site_header)
  File E:\Zope\227194~1.0\lib\python\DocumentTemplate\DT_In.py, line
691, in renderwob
(Object: site_item_list)
  File E:\Zope\227194~1.0\lib\python\DocumentTemplate\DT_Util.py, line
331, in eval
(Object: subject_image(subject))
(Info: subject)
  File E:\Zope\227194~1.0\lib\python\OFS\DTMLMethod.py, line 189, in
validate
(Object: index_html)
  File E:\Zope\227194~1.0\lib\python\AccessControl\SecurityManager.py,
line 139, in validate
  File
E:\Zope\227194~1.0\lib\python\AccessControl\ZopeSecurityPolicy.py, line
159, in validate
Unauthorized: subject

 icon is defined in
 Squishfile as follows:
 
 icon='misc_/Squishdot/squishfile_img'
 
 ...and is protected by the 'View' permission, but you still get the following error:

Traceback (innermost last):
  File E:\Zope\227194~1.0\lib\python\ZPublisher\Publish.py, line 222, in
publish_module
  File E:\Zope\227194~1.0\lib\python\ZPublisher\Publish.py, line 187, in
publish
  File E:\Zope\227194~1.0\lib\python\ZPublisher\Publish.py, line 171, in
publish
  File E:\Zope\227194~1.0\lib\python\ZPublisher\mapply.py, line 160, in
mapply
(Object: index_html)
  File E:\Zope\227194~1.0\lib\python\ZPublisher\Publish.py, line 112, in
call_object
(Object: index_html)
  File E:\Zope\2.2.0\lib\python\Products\Squishdot\Squishdot.py, line
1388, in index_html
(Object: RoleManager)
  File E:\Zope\227194~1.0\lib\python\OFS\DTMLMethod.py, line 167, in
__call__
(Object: posting_html)
  File E:\Zope\227194~1.0\lib\python\DocumentTemplate\DT_String.py, line
502, in __call__
(Object: posting_html)
  File E:\Zope\227194~1.0\lib\python\DocumentTemplate\DT_In.py, line
691, in renderwob
(Object: attachment)
  File E:\Zope\227194~1.0\lib\python\OFS\DTMLMethod.py, line 189, in
validate
(Object: posting_html)
  File E:\Zope\227194~1.0\lib\python\AccessControl\SecurityManager.py,
line 139, in validate
  File
E:\Zope\227194~1.0\lib\python\AccessControl\ZopeSecurityPolicy.py, line
159, in validate
Unauthorized: icon

Any ideas?

cheers,

Chris

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




[Zope-dev] Re: Yup, the problem's still there...

2000-08-22 Thread odysseus


Ah That would explain it!

How about this, instead of an attribute, I created a method:
 def icon(self):
   return 'misc_/Squishdot/squishfile_img'

This seemed to work. Attached is the patch. Comments?

-Lance

On Tue, 22 Aug 2000, Chris Withers wrote:

 Lance wrote:
  I think you have to not only
  inherit RoleManager, but OFS.SimpleItem.Item as well. At least, that's what
  the Security HOWTO seems to imply.
 
 No, it shouldn't :(
 
 SimpleItem.Item has __allow_access_to_unprotected_subobjects__=1 in it,
 so it just masks the problem rather than solving it properly...
 
 cheers,
 
 Chris
 


*** Squishfile.py   Tue Aug 22 09:50:10 2000
--- Squishfile.py.orig  Mon Aug 21 20:21:01 2000
***
*** 127,144 
  from Globals import Persistent  
  from Acquisition import Acquirer  
  from Globals import HTML  
! from ImageFile import ImageFile
! from AccessControl.Role import RoleManager
! 
  #from creosote import spew  

  sep=re.compile('|/|:')  # handle windows(\)/unix(/)/mac(:) path separators  

! class Squishfile(Acquirer,Persistent,RoleManager):  
  """ """  
! __ac_permissions__=(
! ('Use Squishfile Objects',['file_name','file_type','content_type', 
'file_kbytes', 'date_created','date_modified','icon','file_bytes'], ('Anonymous', 
'Manager')),
! )
  _types={'application/octet-stream': 'Binary File',  
  'application/x-gzip' :  'Compressed File',  
  'application/x-compress':   'Compressed File',  
--- 127,141 
  from Globals import Persistent  
  from Acquisition import Acquirer  
  from Globals import HTML  
! from ImageFile import ImageFile  
  #from creosote import spew  

  sep=re.compile('|/|:')  # handle windows(\)/unix(/)/mac(:) path separators  

! class Squishfile(Acquirer,Persistent):  
  """ """  
! icon='misc_/Squishdot/squishfile_img'  
!   
  _types={'application/octet-stream': 'Binary File',  
  'application/x-gzip' :  'Compressed File',  
  'application/x-compress':   'Compressed File',  
***
*** 173,180 
  #spew('sqf ctype: ' + self._ctype)  
  self._created =time.time()  
  self._modified=self._created  
- def icon(self):
-   return 'misc_/Squishdot/squishfile_img'

  def content_type(self):  
  """ content type """  
--- 170,175 
***
*** 213,221 
  return self._file  

  index_html=__repr__  
- 
- 
- 
- 
- 
- 
--- 208,210 



[Zope-dev] Bug in careful_getattr()?

2000-08-22 Thread Jeff Hoffman

Hello,

I have been fighting a problem with PythonMethods/ZClasses. I have a
ZClass, MyTestClass, which has four methods:

  method1 (DTML Method)
  method2 (DTML Method)
  showMethods (DTML Method)
  showMethods2 (PythonMethod)

showMethods is defined as:

  dtml-var standard_html_header
  p
  method1 = dtml-var "_.hasattr(this(), 'method1')"br
  method2 = dtml-var "_.hasattr(this(), 'method2')"br
  nullmethod = dtml-var "_.hasattr(this(), 'nullmethod')"
  /p
  dtml-var standard_html_footer

and showMethods2 is defined:

  print getattr(self, 'method1')
  print getattr(self, 'method2')
  print getattr(self, 'nullmethod')
  return printed

showMethods, when invoked on an instance of my ZClass, returns:

  method1 = 1
  method2 = 1
  nullmethod = 0

Bingo. showMethods2, the PythonMethod, results in an AttributeError in
DT_Util.py:135. Digging into the Zope source, I see:

  validate=md.validate  # line 135

  if validate is None: return v

By inserting some print statements, I notice that md is an empty 
dictionary ([]) when careful_getattr() is called. Therefore, the
validate=md.validate line throws an AttributeError.

I fixed the "problem", and my code as a result, by changing this to read:

  try: validate=md.validate
  except: validate=None

  if validate is None: return v

I have a really strong feeling, though, that I just opened a whole can of
worms. Does my change break an intended behavior of Zope? Is it supposed
to throw an AttributeError when md does not have a 'validate'? If so, is
there a bug in PythonMethods that is causing md to not be initialized
properly before the call to careful_getattr()?

I am pressed for time on this project, and could really use some insight,
here. I am fresh out of ideas, and have hit the limits of my knowledge.

Thanks,

--Jeff

---
Jeff K. Hoffman   704.849.0731 x108
Chief Technology Officer  mailto:[EMAIL PROTECTED]
Going Virtual, L.L.C. http://www.goingv.com/


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




[Zope-dev] Xron and security

2000-08-22 Thread Steve Alexander

Hi Loren,

 I'd be glad to listen to well considered proposals for how Xron should
 handle security.

Consider this a "straw man".


On installation, Xron creates a user in the root user folder called
"XronUser".

Xron is resonsible for setting this user's password. Therefore, it is
known to both the Xron product, and also to the root user folder.

When a Xron method is run, there is a property that indicates whether it
is called anonymously, or authenticated as XronUser.

The Xron product could change the password of XronUser every day to a
new random value.

The domains associated with XronUser could be just localhost.localdomain
(not sure about this). Or based on whatever the machine's host-name is
(probably better).

Site administrators can assign local roles to XronUser as necessary.

If Phillip Eby's proposed changes to the access file get included in
some future version of Zope, XronUser could be included as one of these
bootstrap users by simply writing to a file.

--
Steve Alexander
Software Engineer
Cat-Box ltd
http://www.cat-box.net

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




Re: [Zope-dev] Xron and security

2000-08-22 Thread Loren Stafford

Thanks, Steve.

I have few questions below  8-) (I'm always better with questions than
answers.)

-- Loren

From: "Steve Alexander" [EMAIL PROTECTED]
 Hi Loren,

  I'd be glad to listen to well considered proposals for how Xron should
  handle security.

 Consider this a "straw man".


 On installation, Xron creates a user in the root user folder called
 "XronUser".

 Xron is resonsible for setting this user's password. Therefore, it is
 known to both the Xron product, and also to the root user folder.

 When a Xron method is run, there is a property that indicates whether it
 is called anonymously, or authenticated as XronUser.

Is there a good reason not to always pass authentication in the request? The
authentication property would have to be stored in the Schedule catalog, and
I'd like to keep the Schedule as small as possible.

 The Xron product could change the password of XronUser every day to a
 new random value.

That's more than folks do to maintain secrecy of the "superuser" password.
Is the extra trouble worthwhile?

 The domains associated with XronUser could be just localhost.localdomain
 (not sure about this). Or based on whatever the machine's host-name is
 (probably better).

At a virtual-hosted site, how could Xron know what the host-name is?

 Site administrators can assign local roles to XronUser as necessary.

 If Phillip Eby's proposed changes to the access file get included in
 some future version of Zope, XronUser could be included as one of these
 bootstrap users by simply writing to a file.

 --
 Steve Alexander
 Software Engineer
 Cat-Box ltd
 http://www.cat-box.net




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




[Zope-dev] Patch for extended expression syntax of dtml-tag attributes.

2000-08-22 Thread Adam Karpierz

Very please for discussion and acceptance:

http://classic.zope.org:8080/Collector/1541/view

Regards
--
Adam Karpierz
[EMAIL PROTECTED]



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