RE: [Zope] Re: Blocking Sibling inheritance
Cliff The only issue with this is there are still global items that exist one level up that I want to appear in those folders (\site\item needs to appear in \site\cust1\item and \site\cust2\item). The issue can still happen where you can get an object to appear for \site\cust1\cust2\item (since item needs to be accessable to both cust1 and cust2), and item will pick up the look and feel from cust2.. I would also prefer that if you went to \site\cust1\cust2 you get a 404 type message, but that is secondary to the not showing anything for the cust2 object unless its called from \site\. I understand this is pretty much the exact opposite of the way this product is designed to function. Jay -----Original Message----- From: Cliff Ford [mailto:Cliff.Ford@ed.ac.uk] Sent: Thursday, March 03, 2005 11:35 AM To: Jay Zeemer Cc: zope@zope.org Subject: Re: [Zope] Re: Blocking Sibling inheritance 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@gmail.com] Sent: Thursday, March 03, 2005 3:36 AM To: zope@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@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@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@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 )
I found your initial post scary because it implied that, after login, customer1 could not only see the customer2 site but could also manage it. I have a different architecture and found that was not the case - phew! Maybe you could confirm? I agree that it would be nice to provoke a 404 message. But sometiems that is not what is wanted, for the Zope default header and footer for example. The only merit of my suggestion is that (I think) it would provoke a login sequence that would fail. Not too bad an outcome for one customer trying to hack another's site. And if you don't inherit, then I don't see how you get access to \site\item from \site\customer1\item. Best wishes, Cliff Jay Zeemer wrote:
Cliff The only issue with this is there are still global items that exist one level up that I want to appear in those folders (\site\item needs to appear in \site\cust1\item and \site\cust2\item). The issue can still happen where you can get an object to appear for \site\cust1\cust2\item (since item needs to be accessable to both cust1 and cust2), and item will pick up the look and feel from cust2.. I would also prefer that if you went to \site\cust1\cust2 you get a 404 type message, but that is secondary to the not showing anything for the cust2 object unless its called from \site\. I understand this is pretty much the exact opposite of the way this product is designed to function.
Jay
-----Original Message----- From: Cliff Ford [mailto:Cliff.Ford@ed.ac.uk] Sent: Thursday, March 03, 2005 11:35 AM To: Jay Zeemer Cc: zope@zope.org Subject: Re: [Zope] Re: Blocking Sibling inheritance
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@gmail.com] Sent: Thursday, March 03, 2005 3:36 AM To: zope@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@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@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@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 )
OMG!! I can access management screens, IF and only IF, the Authenticated user role has full permissions assigned in the sibling folders. (which is default isnt it?) If you leave Authenticated users role set to only Access or View objects, then this is not the case. But still! Holy cow! For example I have this folder structure: /dev /dev/test/dir1 /dev/test/dir2 /dev/1stbyte /dev/1stbyte/folder1 /dev/1stbyte/folder2 /dev/tsport /dev/tsport/db /dev/tsport/db-01 /dev/tsport/db-02 If I type in /dev/test/dir1 and consequently authenticate, I get in normally. Then if I continue and change the url to: /dev/test/dir1/dev/tsport/manage I GET IN! All I need to do is add a new user to /dev/test/dir1/dev/tsport/db/acl_users (which I can access) and I've got a user account! That sucks! Remember, this requires that the Authenticated user role has full access at the sibling folder first, which it does. Sorry Cliff, didnt mean to scare ya. :) Though, this is scary a bit I think. On Thu, 03 Mar 2005 19:57:01 +0000, Cliff Ford <Cliff.Ford@ed.ac.uk> wrote:
I found your initial post scary because it implied that, after login, customer1 could not only see the customer2 site but could also manage it. I have a different architecture and found that was not the case - phew! Maybe you could confirm?
I agree that it would be nice to provoke a 404 message. But sometiems that is not what is wanted, for the Zope default header and footer for example. The only merit of my suggestion is that (I think) it would provoke a login sequence that would fail. Not too bad an outcome for one customer trying to hack another's site. And if you don't inherit, then I don't see how you get access to \site\item from \site\customer1\item.
Best wishes,
Cliff
Jay Zeemer wrote:
Cliff The only issue with this is there are still global items that exist one level up that I want to appear in those folders (\site\item needs to appear in \site\cust1\item and \site\cust2\item). The issue can still happen where you can get an object to appear for \site\cust1\cust2\item (since item needs to be accessable to both cust1 and cust2), and item will pick up the look and feel from cust2.. I would also prefer that if you went to \site\cust1\cust2 you get a 404 type message, but that is secondary to the not showing anything for the cust2 object unless its called from \site\. I understand this is pretty much the exact opposite of the way this product is designed to function.
Jay
-----Original Message----- From: Cliff Ford [mailto:Cliff.Ford@ed.ac.uk] Sent: Thursday, March 03, 2005 11:35 AM To: Jay Zeemer Cc: zope@zope.org Subject: Re: [Zope] Re: Blocking Sibling inheritance
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@gmail.com] Sent: Thursday, March 03, 2005 3:36 AM To: zope@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@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@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@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@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
Did anyone have any luck fixing this or finding some kind of solutions? Hosting companies should know about his problem because you would be able to access other client folders if you only know their folder name, and that doesnt take much time to guess on some. I posted a bug report for this, but they make it private, understandably, so nobody knows about it. (except for all us on this list, duh) I havent tried Dario's suggestions yet, but I will eventually. I think they might be an excellent solution. I just wanted to see if anyone had anything tested yet. On Thu, 3 Mar 2005 13:29:15 -0800, Greg Fischer <retheoff@gmail.com> wrote:
OMG!! I can access management screens, IF and only IF, the Authenticated user role has full permissions assigned in the sibling folders. (which is default isnt it?)
If you leave Authenticated users role set to only Access or View objects, then this is not the case. But still! Holy cow!
For example I have this folder structure:
/dev /dev/test/dir1 /dev/test/dir2 /dev/1stbyte /dev/1stbyte/folder1 /dev/1stbyte/folder2 /dev/tsport /dev/tsport/db /dev/tsport/db-01 /dev/tsport/db-02
If I type in /dev/test/dir1 and consequently authenticate, I get in normally.
Then if I continue and change the url to: /dev/test/dir1/dev/tsport/manage
I GET IN! All I need to do is add a new user to /dev/test/dir1/dev/tsport/db/acl_users (which I can access) and I've got a user account! That sucks!
Remember, this requires that the Authenticated user role has full access at the sibling folder first, which it does.
Sorry Cliff, didnt mean to scare ya. :)
Though, this is scary a bit I think.
On Thu, 03 Mar 2005 19:57:01 +0000, Cliff Ford <Cliff.Ford@ed.ac.uk> wrote:
I found your initial post scary because it implied that, after login, customer1 could not only see the customer2 site but could also manage it. I have a different architecture and found that was not the case - phew! Maybe you could confirm?
I agree that it would be nice to provoke a 404 message. But sometiems that is not what is wanted, for the Zope default header and footer for example. The only merit of my suggestion is that (I think) it would provoke a login sequence that would fail. Not too bad an outcome for one customer trying to hack another's site. And if you don't inherit, then I don't see how you get access to \site\item from \site\customer1\item.
Best wishes,
Cliff
Jay Zeemer wrote:
Cliff The only issue with this is there are still global items that exist one level up that I want to appear in those folders (\site\item needs to appear in \site\cust1\item and \site\cust2\item). The issue can still happen where you can get an object to appear for \site\cust1\cust2\item (since item needs to be accessable to both cust1 and cust2), and item will pick up the look and feel from cust2.. I would also prefer that if you went to \site\cust1\cust2 you get a 404 type message, but that is secondary to the not showing anything for the cust2 object unless its called from \site\. I understand this is pretty much the exact opposite of the way this product is designed to function.
Jay
-----Original Message----- From: Cliff Ford [mailto:Cliff.Ford@ed.ac.uk] Sent: Thursday, March 03, 2005 11:35 AM To: Jay Zeemer Cc: zope@zope.org Subject: Re: [Zope] Re: Blocking Sibling inheritance
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@gmail.com] Sent: Thursday, March 03, 2005 3:36 AM To: zope@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@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@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@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@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
Dario, thanks for the advice. I'll try it out and see how it works, seems like it would work great. I'll let you know. Chris, That's the first thing I thougt too, but it's not the case. I am attaching a zexp for you guys to import (if you want) and test this. This is simple to reproduce. - In the folder test, there are 'dir1' and 'dir2' folders. - Each folder has their own user accounts, 'dir1' user and 'dir2' user respectively. Password is '1' and '2' (simple here) - Try to open that folder: /test/dir1/page You must authenticate as dir1 user. - Next do this: /test/dir1/dir2/page You will get the page object in dir2 without auth! Note that the security on each is set to NOT Acquire and no anonymous access. If anyone would like I'll post even more detailed instructions to setup and reproduce. I found a users post by a guy named Jack, who posted on the python list the other day. He noticed this problem and I said, "No way! Zope doesnt do that!" After some emails with him, I found, that it sure enough did. Anyway, Jack found this, I just couldnt leave it alone and then I saw your post Jay. Could it be nobody has thought of this one yet? Cliff, just wanted to say that I think that might work, havent tested it, but I did think about that. Dario has a better solution though. I think that this is problem that needs to be addressed and not simply worked around. I also think it would be a pain to manage security that way. If you had lot's of hosted clients, that would be bothersome. In small cases, though, it's worth testing. I've never put anything in as a bug report, but I'll go ahead and put this up. Seems like a big security hole to me too. Thanks all! Greg On Thu, 3 Mar 2005 13:15:21 -0500, Jay Zeemer <jzeemer@edcor.com> wrote:
Cliff The only issue with this is there are still global items that exist one level up that I want to appear in those folders (\site\item needs to appear in \site\cust1\item and \site\cust2\item). The issue can still happen where you can get an object to appear for \site\cust1\cust2\item (since item needs to be accessable to both cust1 and cust2), and item will pick up the look and feel from cust2.. I would also prefer that if you went to \site\cust1\cust2 you get a 404 type message, but that is secondary to the not showing anything for the cust2 object unless its called from \site\. I understand this is pretty much the exact opposite of the way this product is designed to function.
Jay
-----Original Message----- From: Cliff Ford [mailto:Cliff.Ford@ed.ac.uk] Sent: Thursday, March 03, 2005 11:35 AM To: Jay Zeemer Cc: zope@zope.org Subject: Re: [Zope] Re: Blocking Sibling inheritance
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@gmail.com] Sent: Thursday, March 03, 2005 3:36 AM To: zope@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@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@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@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@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
participants (3)
-
Cliff Ford -
Greg Fischer -
Jay Zeemer