[Zope] Re: Re: Blocking Sibling inheritance

Wed Mar 9 05:59:55 EST 2005

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