[Zope] Re: Re: Blocking Sibling inheritance

Greg Fischer retheoff at gmail.com
Wed Mar 9 10:15:50 EST 2005 

Thanks Malcolm!

That is a fairly simple solution, right on man!




On Wed, 09 Mar 2005 10:59:55 +0000, Malcolm Cleaton <malcolm at jamkit.com> wrote:
> The issue can be worked around more easily than this. It is only the magic
> "Authenticated" role which appears to suffer from this problem.
> 
> You can create a role in the parent of your client folders, and assign
> users in each client folder's acl_users to that same role, and they'll
> still only get access according to that role within the appropriate scope.
> 
> Thanks,
> Malcolm.
> 
> 
> On Thu, 03 Mar 2005 16:34:55 +0000, Cliff Ford wrote:
> > Something to ponder:
> >
> > What if each customer folder had its own local role, such as manager1
> > for customer1, manager2 for customer 2, etc, and the local role was the
> > only role granted access in its own folder. That would be easy to set up
> > and has to beat adding an "object to every customer folder that
> > represents every other customer".
> >
> > Cliff
> >
> > Jay Zeemer wrote:
> >> Greg,
> >> You just described my problem to the letter.  This is the issue that is
> >> impacting me currently.  The only way we have successfully blocked this is
> >> to add an object to every customer folder that represents every other
> >> customer.  We have been trying to make a folder-ish object with
> >> Acquisition.Implicit but so far have had no success.  Besides adding a
> >> customer# object for every customer to every customer can anyone tell me how
> >> I can block this from happening??
> >>
> >> Jay
> >>
> >> -----Original Message-----
> >> From: Greg Fischer [mailto:retheoff at gmail.com]
> >> Sent: Thursday, March 03, 2005 3:36 AM
> >> To: zope at zope.org
> >> Subject: Re: [Zope] Re: Blocking Sibling inheritance
> >>
> >>
> >> Security issue?  I think you are partially right about it not being a
> >> security issue because Zope does what it is supposed to do and look
> >> where it should.
> >>
> >> Here is a security issue relating to this acquisition:  (IMHO)
> >>
> >> I have folder 1:  /site/dev/customer1/folder/page
> >> And folder 1:    /site/dev/customer2/folder1/folder2/page
> >>
> >> Eash customer level folder has acl_users with different/separate
> >> accounts.  The security at the customer level folder is set to not
> >> acquire and no anonymous access.  Now here is the problem I see, you
> >> type in your URL:
> >> someplace.com/site/dev/customer1/folder/page
> >>
> >> You are asked to authenticate.  Then you change your url after
> >> authentication to:
> >> somplace.com/site/dev/customer1/folder/customer2/folder1/folder1/page
> >>
> >> And you get right in with no authentication!  That should not be allowable.
> >>
> >> I understand that this would require someone to know the folder
> >> structures, but really, in a more simplistic example, all you would
> >> need to know is the other client folder name, and you would have
> >> access.
> >>
> >> So what can we do about this?  If you dont have acl-users account in a
> >> folder you access, you should NOT be able to see the contents.  Right?
> >>
> >> This may be a new subject, I dont mean to stray off topic.
> >>
> >>
> >> On Thu, 3 Mar 2005 01:20:32 -0700, kosh <kosh at aesaeion.com> wrote:
> >>
> >>>On Thursday 03 March 2005 1:06 am, Dario Lopez-Kästen wrote:
> >>>
> >>>>Tres Seaver wrote:
> >>>>
> >>>>>-----BEGIN PGP SIGNED MESSAGE-----
> >>>>>Hash: SHA1
> >>>>>
> >>>>>Jay Zeemer wrote:
> >>>>>| Greetings all,
> >>>>>| I am in the process of examining Zope for some possible
> >>
> >> applications.
> >>
> >>>>>| Currently I am having an issue with Zope being a bit to smart.  I
> >>
> >> have
> >>
> >>>>>| a directory \Dir1\ and under it I have 2 subdirectories \Dir1\SubA\
> >>
> >> and
> >>
> >>>>>| \Dir1\SubB\.  The problem I am having is I can go to
> >>
> >> \Dir1\SubA\SubB\
> >>
> >>>>>| and gain access to things that are in \Dir1\SubB\, I need to be able
> >>
> >> to
> >>
> >>>>>| block sibling level inheritance.  Is this possible in Zope??  Or are
> >>>>>| there any other ways to block this with out creating a SubB object
> >>
> >> in
> >>
> >>>>>\Dir1\SubA\ ??
> >>>>>
> >>>>>The "sibling inheritance" you are describing is Zope's "acquisition".
> >>>>>Folders derive from Acquisition.Implicit, which means they are willing
> >>>>>to acquire any "non-private" name from their parents.
> >>>>>
> >>>>>To prevent this behavior, place SubA with a Folder-like object which
> >>>>>derives instead from Acquisition.Explicit.
> >>>>
> >>>>I'd need this too. Would I be making a correct assumption when stating
> >>>>that no such folderish product, such as a "aq-blocking Folder", exists
> >>>>yet, but it has to be written (ie by me or anyonelse needing this
> >>>>functionality)?
> >>>>
> >>>>Thanks.
> >>>>
> >>>
> >>>I don't know of something like this existing and even more I don't know
> >>
> >> why
> >>
> >>>you would really want it. Eventually you will understand how and why
> >>>acquisition works and then you would have a fair bit of work to do to
> >>
> >> change
> >>
> >>>the stuff back. Zope is not publishing any object that the person viewing
> >>
> >> the
> >>
> >>>site would not normally have access to so it is not  security issue.
> >>>
> >>>What you probably need to do is read the zope book and read about how
> >>>acquisition works. You can use it to make apps a lot faster and save
> >>
> >> yourself
> >>
> >>>a lot of work by learning how to use it. Acquisition is a major reason
> >>
> >> that I
> >>
> >>>use zope in the first place and have been using it for about 4 years now.
> >>>_______________________________________________
> >>>Zope maillist  -  Zope at zope.org
> >>>http://mail.zope.org/mailman/listinfo/zope
> >>>**   No cross posts or HTML encoding!  **
> >>>(Related lists -
> >>> http://mail.zope.org/mailman/listinfo/zope-announce
> >>> http://mail.zope.org/mailman/listinfo/zope-dev )
> >>>
> >>
> >>
> >>
> > _______________________________________________
> > Zope maillist  -  Zope at zope.org
> > http://mail.zope.org/mailman/listinfo/zope
> > **   No cross posts or HTML encoding!  **
> > (Related lists -
> >  http://mail.zope.org/mailman/listinfo/zope-announce
> >  http://mail.zope.org/mailman/listinfo/zope-dev )
> --
> 
>     [] j a m k i t
>       web solutions for charities
> 
>          malcolm cleaton
> T:  020 7549 0520
> F:  020 7490 1152
> M:  07986 563852
> W: www.jamkit.com
> 
> 
> _______________________________________________
> Zope maillist  -  Zope at zope.org
> http://mail.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope-dev )
> 


-- 
Greg Fischer
1st Byte Solutions
http://www.1stbyte.com

More information about the Zope mailing list