RE: [Zope] Zope and security.
It seems to me you cannot securely allow users access to the "Security" tab in the management interface. It's easy enough to shut this off, but that does take away an awful lot of functionality. Is this an intended design, or is it a flaw in the Zope security model?
It is possible to do what you are asking (with a few caveats). Local roles let you give a user roles *only in the context of a particular object* rather than associating the roles directly with the user. The easiest way to accomplish what you are asking: There is a predefined "Owner" role in Zope. When a user creates an object, he/she is automatically given the local role "Owner" on that object. Lets say you want to totally delegate control of the "Reports" area of your site to Fred. First, create a "Reports" folder somewhere on your site. Now go to the "Security" tab of the Folder and click on "local roles" and give Fred the "Owner" local role. Now, go up at least one folder (or even all the way to the top of the site) and on the "Security" screen give the "Owner" role all of the permissions you want Folder owners to have on their area (this can include the "Change Permissions" permission too). Now, Fred will have all of the permissions associated with the "Owner" role - but only in _his_ Folder, where he has the local role "Owner". In other words, he could see and use the "Security" tab in _his_ Folder, but if he went higher up in the site he couldn't (because he doesn't have the local role "Owner" there). Now the caveat: when you give someone the "Change permissions" permission, you are effectively trusting him as a Manager in his own area. Though he can't affect things outside his area, it is not really possible to actually restrict what he can do in his own area once you've given "Change permissions". This is because he is now free to give himself any permission he wants (in his own folder) if he doesn't already have it. It is possible that this behavior could be modified in the future (by enforcing some rules whereby a user can only modify roles or permissions that he already has), but some thought would need to go into this to be sure that there is a real need for it and that the behavior is well understood. Hope this helps! Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
Brian Lloyd wrote:
[snip things that seem to confirm my understanding :) ]
Now the caveat: when you give someone the "Change permissions" permission, you are effectively trusting him as a Manager in his own area. Though he can't affect things outside his area, it is not really possible to actually restrict what he can do in his own area once you've given "Change permissions". This is because he is now free to give himself any permission he wants (in his own folder) if he doesn't already have it.
And that's exactly the problem I see. If I take away "Create ZSQL Methods" from his home folder but don't take away the security tab, he can put it right back. If I'm using UserDB to authenticate he can just create a Z SQL Method that queries the db for userid's and passwords. So I get clever and take away his Security tab (which, btw, means he can't control who sees his objects) but forget to take away his ability to create folders, he creates a new folder changes the permissions on it so he can create Z SQL Methods and we're back to square one. It seems the only way to securely handle all this is to roll your own folder that can't hold Z SQL Methods, or anything else that users don't really need. (Incidentally, if I did this with Z Classes, would there be any performance implications?)
It is possible that this behavior could be modified in the future (by enforcing some rules whereby a user can only modify roles or permissions that he already has), but some thought would need to go into this to be sure that there is a real need for it and that the behavior is well understood.
That would probably wouldn't solve the problem, unless you acquisition were involved. Otherwise you could easily circumvent it by creating a new folder and doing whatever you please there. Would it be possible with Z Classes to modify either the constructor or the addForm to restrict who can create certain objects? Would it be possible in Python products? That seems to be the appropriate place to control what objects can be created by whom. -Otto.
On 11/11/99 11:57 AM, Otto Hammersmith at otto@ipass.net wrote:
If I take away "Create ZSQL Methods" from his home folder but don't take away the security tab, he can put it right back. If I'm using UserDB to authenticate he can just create a Z SQL Method that queries the db for userid's and passwords.
How about using security in the database? I'd never consider using the same login/password for UserDB that I used for application data, ever. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
Christopher Petrilli wrote:
How about using security in the database? I'd never consider using the same login/password for UserDB that I used for application data, ever.
Very true, but that only prevents compromising security at other places (and likely compromises other "portal" accounts). I assume you're suggesting something like crypt()'ed passwords... or are you suggesting some authentication between the SQL Method and the database connection? -Otto.
On Thu, 11 Nov 1999, Otto Hammersmith wrote:
It seems the only way to securely handle all this is to roll your own folder that can't hold Z SQL Methods, or anything else that users don't really need. (Incidentally, if I did this with Z Classes, would there be any performance implications?)
Write manage_safeaccessForm and manage_safeaccess DTML methods. Give manage_safeaccess the manager proxy role. manage_safeacessForm is simply a form that allows you to do a subset of the normal security form. manage_safeaccess sanitizes the request and passes the results through to the relevant change-permissions method. This way a user with access to manage_safeaccessForm and manage_safeaccess can alter whatever subset of permissions you define in a folder, and all subfolders through aquisition. But not individual objects.
Would it be possible with Z Classes to modify either the constructor or the addForm to restrict who can create certain objects? Would it be possible in Python products? That seems to be the appropriate place to control what objects can be created by whom.
You can check what roles the current AUTHENTICATED_USER has, and raise an exception if they should be able to create this object. You would need to call: folder.get_local_roles_for_userid(AUTHENTICATED_USER.getUserName()) Assuming folder is the folder your ZClass or Python product is being added to. ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen
participants (5)
-
Brian Lloyd -
Christopher Petrilli -
Otto -
Otto Hammersmith
-
Stuart 'Zen' Bishop