Re: [Zope3-dev] security problems with database adapters (second edition)
Velko Ivanov wrote: Dmitry Vasiliev wrote: Maybe we need always check security map at the root folder? I don't believe this is the solution. Altrough it will solve my example, it wouldn't help in other scenarios. I would eventually make ZopeConnection and ZopeCursor locatable, if they aren't already, and assign the database adapter as the parent of the connection and the connection to the cursor at the time of their creation. Actually I'm going to patch it like that right away. ZopeConnection and ZopeCursor not only an objects without an location, see for example '/++etc++process' so I think it is the UI grant tool problem. I'll post an issue to the collector. One last question, to clear things a bit for me, as I don't have a Zope3 copy here to try - Imagine the user accesses some python class by the means of submiting a form and that class needs to do some work with the database, so it obtains a database connection, creates a cursor and executes some queries. In this case, will the class access the connection with the user's privileges, or is it trusted ? If it is trusted, my problem here is not of so big importance, but if not, I imagine zope.app.rdb needs some urgent updates. I don't believe that I'm currently fully understand whole Z3's security system, :-) but I think you can manage access rights through 'permission' attribute of the form's ZCML directive. For instance in one of my projects there is a pages which use a database connection with 'zope.Public' and 'zope.ManageContent' permissions. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] security problems with database adapters (second edition)
Dmitry Vasiliev wrote: zope.app.securitypolicy.zopepolicy.ZopeSecurityPolicy does the following: 1. check for security map at /aFolder 2. get the aFolder's parent (the root folder in our case) through the '__parent__' attribute 3. check for security map at / 4. check global security map defined through configuration If object doesn't have a '__parent__' attribute and any associated security map the security check will be based only on global security map. Oh, now I see it. Thanks :) Maybe we need always check security map at the root folder? I don't believe this is the solution. Altrough it will solve my example, it wouldn't help in other scenarios. I would eventually make ZopeConnection and ZopeCursor locatable, if they aren't already, and assign the database adapter as the parent of the connection and the connection to the cursor at the time of their creation. Actually I'm going to patch it like that right away. One last question, to clear things a bit for me, as I don't have a Zope3 copy here to try - Imagine the user accesses some python class by the means of submiting a form and that class needs to do some work with the database, so it obtains a database connection, creates a cursor and executes some queries. In this case, will the class access the connection with the user's privileges, or is it trusted ? If it is trusted, my problem here is not of so big importance, but if not, I imagine zope.app.rdb needs some urgent updates. Regards, Velko Ivanov ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] security problems with database adapters (second edition)
Velko Ivanov wrote: The problem is easy to reproduce in a few simple steps - assuming clean installation from the .tgz release, here is what I do: 1. create an instance (of course), zope.Manager granted principal is crated by the mkzopeinstance script. 2. uncomment the sample zope.Member principal 'frodo' in principals.zcml and run zope -- using the browser from now on: 3. login with the zope.Manager principal use the grant tool to grant zope.Manager role at the top of the site to the 'frodo' principal 4. go to manage site -> site management and add a database adapter, gadfly will do, dbi is something in the form of dbi://dbname;dir=/tmp, or any other dir as apropriate 5. login as frodo and go to /++etc++site/tools/yourdbaname 6. select the test page and just click on 'execute' 7. unauthorized 8. if you try (5),(6) with the zope.Manager principal, you will see the database adapter working as expected (producing an error in this example actually, but not 'unauthorized' exception) Ugh. The problem seems is that the UI grant tool work only for locatable objects like folders, pages and so on. For example if you go to /@@grant.html and grant some role/permission for a principal a local security map will be stored in the root folder annotations. Then if you access some folder at /aFolder zope.app.securitypolicy.zopepolicy.ZopeSecurityPolicy does the following: 1. check for security map at /aFolder 2. get the aFolder's parent (the root folder in our case) through the '__parent__' attribute 3. check for security map at / 4. check global security map defined through configuration Then global security declarations will be overridden by local security declarations. If object doesn't have a '__parent__' attribute and any associated security map the security check will be based only on global security map. Maybe we need always check security map at the root folder? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] security problems with database adapters (second edition)
I forgot to add cc: for the list, sorry Dmitry Vasiliev wrote: >> Looking at the code, the ZopeConnection object is created by the ZopeDatabaseAdapter class in zope.app.rdb (inherited by the actual DatabaseAdapter) with a simple call - self._v_connection = ZopeConnection(self._connection_factory(), self) >> and the ZopeConnection class does not have anything, that deals with security, as far as I can see. > > > > See zope/app/rdb/configure.zcml for security declarations. > I mean - I see in the zcml configuration, that zope.ManageContent permission is required for ZopeConnection, but I don't see what in the ZopeConnection object could provide it for the user. So my explanation is that the security policy simply allows one special kind of user in all cases, without ever checking permission and actually I found exactly the code, that does that, by seeing if the user is system_user and just granting access if yes. I didn't go deep enough to confirm that a user with zope.Manager granted _from principals.zcml_ is assigned that property, it's just my guess. However, it seems to me that when the zope.Manager role is granted by the UI grant tool, the user doesn't get system_user, permissions are cheked, a proxy is not found for the ZopeConnection and access is denied in all cases. I can eventually create a functional test to demonstrate, but it will take too much effort to browse around for the bits I need (since it is a really good framework and code, but it is a complete nightmare for the newcommer to follow the logic trough it). The problem is easy to reproduce in a few simple steps - assuming clean installation from the .tgz release, here is what I do: 1. create an instance (of course), zope.Manager granted principal is crated by the mkzopeinstance script. 2. uncomment the sample zope.Member principal 'frodo' in principals.zcml and run zope -- using the browser from now on: 3. login with the zope.Manager principal use the grant tool to grant zope.Manager role at the top of the site to the 'frodo' principal 4. go to manage site -> site management and add a database adapter, gadfly will do, dbi is something in the form of dbi://dbname;dir=/tmp, or any other dir as apropriate 5. login as frodo and go to /++etc++site/tools/yourdbaname 6. select the test page and just click on 'execute' 7. unauthorized 8. if you try (5),(6) with the zope.Manager principal, you will see the database adapter working as expected (producing an error in this example actually, but not 'unauthorized' exception) > > > Can you repeat all this experiments on clean Z3 setup (without any additional components and without your old Data.fs file, check also for all possibly conflicting modules on the PYTHONPATH)? > I just downloaded Zope-3.1.0c2, installed it clean and got the same behaviour. I am using python 2.4.1 and I will check with 2.3.5 if needed, but I saw enough Zope3 code already and I don't think this will change anything. I don't have much idea what module could be conflicting in the case of Zope3 and database adapters. The setup is clean, the test machine is freshly configured and I don't see what could get in the way, but I will check that more carefully too, if you can not reproduce the error at your side. Regards, Velko Ivanov P.s.: I changed the permissions for ZopeConnection, ZopeCursor and ZopeRow in zope/app/rdb/configure.zcml to zope.Public and it of course works, but that is again by going around the security policy, as with the system_user - it is just unconditionally allowing acces if the permission is zope.Public ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] security problems with database adapters (second edition)
Velko Ivanov wrote: Hello, My problems on this subject didn't get resolved since my last post, but I have some new info and questions - The sympthoms (Zope 3.1.0c1): Database adapters are not usable by principals other than the zope.Manager, in the principals.zcml file. Any other principal is unauthenticated - I tried principals.zcml regular user with zope.ManageContent, zope.UseDatabaseConnections and zope.View granted, pluggable authentication user with the zope.Manager role granted, and finally - principals.zcml regular user with zope.Manager role. All principals are able to see and manage the connection object, but can't retrieve results. This is tested and true for both psycopg and Gadfly database adapters. This is the exception I get when trying to use SQL script: * Module zope.app.sqlscript.browser.sqlscript, line 39, in getArguments for argname, argvalue in self.context.getArguments().items(): Unauthorized: (0xa03e86c>, 'items', 'zope.ManageContent') This is the excpetion from the test page of the connection object (in /++etc++site/tools) when I use principal with zope.Manager granted: * Module zope.app.rdb, line 372, in queryForResults cursor = conn.cursor() Unauthorized: (, 'cursor', 'zope.ManageContent') Hmm... Database adapter working just fine for me. Looking at the code, the ZopeConnection object is created by the ZopeDatabaseAdapter class in zope.app.rdb (inherited by the actual DatabaseAdapter) with a simple call - self._v_connection = ZopeConnection(self._connection_factory(), self) and the ZopeConnection class does not have anything, that deals with security, as far as I can see. See zope/app/rdb/configure.zcml for security declarations. My question is, does this eventually mean, that ZopeConnection objects, which are created at run-time, are not security proxied and consequently unauthorized in all cases (except the system_user) and if yes, what should be done? I'm not familiar with the Zope3 environment and I don't know how and where objects get proxied. Or is there something I'm missing here ? Can you repeat all this experiments on clean Z3 setup (without any additional components and without your old Data.fs file, check also for all possibly conflicting modules on the PYTHONPATH)? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] security problems with database adapters (second edition)
On Friday 26 August 2005 11:51, Velko Ivanov wrote: > My question is, does this eventually mean, that ZopeConnection objects, > which are created at run-time, are not security proxied and consequently > unauthorized in all cases (except the system_user) and if yes, what > should be done? I'm not familiar with the Zope3 environment and I don't > know how and where objects get proxied. > Or is there something I'm missing here ? I think Dimitry addressed this problem. Is it still a problem? If so, do you have enough experience to produce a functional test demonstrating the problem? Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] security problems with database adapters (second edition)
Hello, My problems on this subject didn't get resolved since my last post, but I have some new info and questions - The sympthoms (Zope 3.1.0c1): Database adapters are not usable by principals other than the zope.Manager, in the principals.zcml file. Any other principal is unauthenticated - I tried principals.zcml regular user with zope.ManageContent, zope.UseDatabaseConnections and zope.View granted, pluggable authentication user with the zope.Manager role granted, and finally - principals.zcml regular user with zope.Manager role. All principals are able to see and manage the connection object, but can't retrieve results. This is tested and true for both psycopg and Gadfly database adapters. This is the exception I get when trying to use SQL script: * Module zope.app.sqlscript.browser.sqlscript, line 39, in getArguments for argname, argvalue in self.context.getArguments().items(): Unauthorized: (0xa03e86c>, 'items', 'zope.ManageContent') This is the excpetion from the test page of the connection object (in /++etc++site/tools) when I use principal with zope.Manager granted: * Module zope.app.rdb, line 372, in queryForResults cursor = conn.cursor() Unauthorized: (, 'cursor', 'zope.ManageContent') Looking at the code, the ZopeConnection object is created by the ZopeDatabaseAdapter class in zope.app.rdb (inherited by the actual DatabaseAdapter) with a simple call - self._v_connection = ZopeConnection(self._connection_factory(), self) and the ZopeConnection class does not have anything, that deals with security, as far as I can see. My question is, does this eventually mean, that ZopeConnection objects, which are created at run-time, are not security proxied and consequently unauthorized in all cases (except the system_user) and if yes, what should be done? I'm not familiar with the Zope3 environment and I don't know how and where objects get proxied. Or is there something I'm missing here ? Regards, Velko Ivanov ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
