[Zope] Re: Re: Blocking Sibling inheritance

Wed Mar 9 10:17:13 EST 2005

oh, forgot to specify, you must remove any security settings for
'Authenticated' and add them to the new role for this to work.

Thanks!

On Wed, 9 Mar 2005 07:15:50 -0800, Greg Fischer <retheoff at gmail.com> wrote:
> 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
> 

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