RE: [Zope] Re: Blocking Sibling inheritance
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 )
-- Greg Fischer 1st Byte Solutions http://www.1stbyte.com _______________________________________________ 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 )
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??
here is an idea, infering from a quick reading of sources. Would the below work? in ..../lib/python/OFS is where Folder is defined folder is defined as: class Folder( ObjectManager.ObjectManager, PropertyManager.PropertyManager, AccessControl.Role.RoleManager, webdav.Collection.Collection, SimpleItem.Item, FindSupport.FindSupport, ): SimpelItem is defined as: class SimpleItem(Item, Globals.Persistent, Acquisition.Implicit, AccessControl.Role.RoleManager, ): so, if we copy the source for SimpleItem, and redefined it as such: class SimpleItemNoAq(Item, Globals.Persistent, Acquisition.Explicit, # <----- AccessControl.Role.RoleManager, ): and create a new Folder class (also mor or less copying the origial code): class Folder( ObjectManager.ObjectManager, PropertyManager.PropertyManager, AccessControl.Role.RoleManager, webdav.Collection.Collection, SimpleItemNoAq.Item, # <----- FindSupport.FindSupport, ): would this work as what we discussed earlier? Thanks, /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. "...and click? damn, I need to kill -9 Word again..." - b using macosx
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 )
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@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 ) --
[] 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
Thanks Malcolm! That is a fairly simple solution, right on man! On Wed, 09 Mar 2005 10:59:55 +0000, Malcolm Cleaton <malcolm@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@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 ) --
[] 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@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
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@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@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@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 ) --
[] 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@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
Malcolm Cleaton wrote at 2005-3-9 10:59 +0000:
The issue can be worked around more easily than this. It is only the magic "Authenticated" role which appears to suffer from this problem.
It should not be necessary: A user should not be able to access any *protected* (!) object outside the subhierarchy governed by the user folder that authenticated the user. But maybe, we have a bug (and "aq_inContextOf" does not work as expected). -- Dieter
Dieter, It is possible, unless you take the "Authenticated" role off. (by unchecking in security) I thought as you did, it should not be possible. Here is bit from a previous post I did: ========================== 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 --- Each of the lower subfolders (dir1, db, folder1 and 2) have their own acl_users and user accounts --- 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! ========================== This is not cool! I did post a bug report, but havnt heard anything yet. Malcolms workaround works, you just need to remove "Authenticated" role and add a custom one. I'd like to test Dario's solution, adding "non-acquiring" folders might be nice. But really, it should be fixed at the lowest level possible I would think. Greg On Wed, 9 Mar 2005 19:23:53 +0100, Dieter Maurer <dieter@handshake.de> wrote:
Malcolm Cleaton wrote at 2005-3-9 10:59 +0000:
The issue can be worked around more easily than this. It is only the magic "Authenticated" role which appears to suffer from this problem.
It should not be necessary:
A user should not be able to access any *protected* (!) object outside the subhierarchy governed by the user folder that authenticated the user.
But maybe, we have a bug (and "aq_inContextOf" does not work as expected).
-- Dieter _______________________________________________ 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
On Wed, 09 Mar 2005 19:23:53 +0100, Dieter Maurer wrote:
Malcolm Cleaton wrote at 2005-3-9 10:59 +0000:
The issue can be worked around more easily than this. It is only the magic "Authenticated" role which appears to suffer from this problem.
It should not be necessary:
A user should not be able to access any *protected* (!) object outside the subhierarchy governed by the user folder that authenticated the user.
But maybe, we have a bug (and "aq_inContextOf" does not work as expected).
Yes, this shouldn't be necessary, and it looks like it's a bug. Looks to me like the bug is in User.py's allowed method. Quite simply, when it checks for the Authenticated role, it doesn't call self._check_context, so never attempts to detect and foil acquisition tricks. Unless I'm missing something, it should be a quick and easy fix. Thanks, Malcolm. -- [] 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
Please put this in the collector or it may get lost. Thanks, Stefan On 10. Mär 2005, at 11:07, Malcolm Cleaton wrote:
On Wed, 09 Mar 2005 19:23:53 +0100, Dieter Maurer wrote:
Malcolm Cleaton wrote at 2005-3-9 10:59 +0000:
The issue can be worked around more easily than this. It is only the magic "Authenticated" role which appears to suffer from this problem.
It should not be necessary:
A user should not be able to access any *protected* (!) object outside the subhierarchy governed by the user folder that authenticated the user.
But maybe, we have a bug (and "aq_inContextOf" does not work as expected).
Yes, this shouldn't be necessary, and it looks like it's a bug.
Looks to me like the bug is in User.py's allowed method. Quite simply, when it checks for the Authenticated role, it doesn't call self._check_context, so never attempts to detect and foil acquisition tricks. Unless I'm missing something, it should be a quick and easy fix.
Thanks, Malcolm.
-- Software Engineering is Programming when you can't. --E. W. Dykstra
I did last week. On Thu, 10 Mar 2005 16:18:42 +0100, Stefan H. Holek <stefan@epy.co.at> wrote:
Please put this in the collector or it may get lost.
Thanks, Stefan
On 10. Mär 2005, at 11:07, Malcolm Cleaton wrote:
On Wed, 09 Mar 2005 19:23:53 +0100, Dieter Maurer wrote:
Malcolm Cleaton wrote at 2005-3-9 10:59 +0000:
The issue can be worked around more easily than this. It is only the magic "Authenticated" role which appears to suffer from this problem.
It should not be necessary:
A user should not be able to access any *protected* (!) object outside the subhierarchy governed by the user folder that authenticated the user.
But maybe, we have a bug (and "aq_inContextOf" does not work as expected).
Yes, this shouldn't be necessary, and it looks like it's a bug.
Looks to me like the bug is in User.py's allowed method. Quite simply, when it checks for the Authenticated role, it doesn't call self._check_context, so never attempts to detect and foil acquisition tricks. Unless I'm missing something, it should be a quick and easy fix.
Thanks, Malcolm.
-- Software Engineering is Programming when you can't. --E. W. Dykstra
_______________________________________________ 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
Malcolm Cleaton wrote at 2005-3-10 10:07 +0000:
...
It should not be necessary:
A user should not be able to access any *protected* (!) object outside the subhierarchy governed by the user folder that authenticated the user.
But maybe, we have a bug (and "aq_inContextOf" does not work as expected).
Yes, this shouldn't be necessary, and it looks like it's a bug.
Looks to me like the bug is in User.py's allowed method. Quite simply, when it checks for the Authenticated role, it doesn't call self._check_context, so never attempts to detect and foil acquisition tricks. Unless I'm missing something, it should be a quick and easy fix.
You are right! -- Dieter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dieter Maurer wrote: | Malcolm Cleaton wrote at 2005-3-10 10:07 +0000: | |>... |> |>>It should not be necessary: |>> |>> A user should not be able to access any *protected* (!) object |>> outside the subhierarchy governed by the user folder |>> that authenticated the user. |>> |>>But maybe, we have a bug (and "aq_inContextOf" does not work |>>as expected). |> |>Yes, this shouldn't be necessary, and it looks like it's a bug. |> |>Looks to me like the bug is in User.py's allowed method. Quite simply, |>when it checks for the Authenticated role, it doesn't call |>self._check_context, |>so never attempts to detect and foil acquisition |>tricks. Unless I'm missing something, it should be a quick and easy fix. | | | You are right! Yep. The only hard part will be writing a decent unit test which exercises the bug: - -------------------- 8< ------------------ diff -u -r1.176.14.7 User.py - --- lib/python/AccessControl/User.py 25 Jan 2005 13:46:14 -0000 1.176.14.7 +++ lib/python/AccessControl/User.py 10 Mar 2005 20:26:53 -0000 @@ -182,7 +182,8 @@ ~ # role and user is not nobody ~ if 'Authenticated' in object_roles and ( ~ self.getUserName() != 'Anonymous User'): - - return 1 + if self._check_context(object): + return 1 ~ # Check for ancient role data up front, convert if found. ~ # This should almost never happen, and should probably be - -------------------- 8< ------------------ Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMK2AGqWXf00rNCgRAux+AJ0Zas9R/lUMc+Oot05jl5TNbunQLACeKBlt ZgoCjc6pOE8AjdSy6a7CUj8= =RLrC -----END PGP SIGNATURE-----
Thank for that Tres! It works great! Greg On Thu, 10 Mar 2005 15:26:41 -0500, Tres Seaver <tseaver@zope.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dieter Maurer wrote: | Malcolm Cleaton wrote at 2005-3-10 10:07 +0000: | |>... |> |>>It should not be necessary: |>> |>> A user should not be able to access any *protected* (!) object |>> outside the subhierarchy governed by the user folder |>> that authenticated the user. |>> |>>But maybe, we have a bug (and "aq_inContextOf" does not work |>>as expected). |> |>Yes, this shouldn't be necessary, and it looks like it's a bug. |> |>Looks to me like the bug is in User.py's allowed method. Quite simply, |>when it checks for the Authenticated role, it doesn't call |>self._check_context, |>so never attempts to detect and foil acquisition |>tricks. Unless I'm missing something, it should be a quick and easy fix. | | | You are right!
Yep. The only hard part will be writing a decent unit test which exercises the bug:
- -------------------- 8< ------------------ diff -u -r1.176.14.7 User.py - --- lib/python/AccessControl/User.py 25 Jan 2005 13:46:14 -0000 1.176.14.7 +++ lib/python/AccessControl/User.py 10 Mar 2005 20:26:53 -0000 @@ -182,7 +182,8 @@ ~ # role and user is not nobody ~ if 'Authenticated' in object_roles and ( ~ self.getUserName() != 'Anonymous User'): - - return 1 + if self._check_context(object): + return 1
~ # Check for ancient role data up front, convert if found. ~ # This should almost never happen, and should probably be - -------------------- 8< ------------------
Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCMK2AGqWXf00rNCgRAux+AJ0Zas9R/lUMc+Oot05jl5TNbunQLACeKBlt ZgoCjc6pOE8AjdSy6a7CUj8= =RLrC -----END PGP SIGNATURE-----
_______________________________________________ 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 (8)
-
Cliff Ford -
Dario Lopez-Kästen -
Dieter Maurer -
Greg Fischer -
Jay Zeemer -
Malcolm Cleaton -
Stefan H. Holek -
Tres Seaver