This release contains the new changes to the Zope security model to protect against the server-side trojan issue:
http://www.zope.org/Members/jim/ZopeSecurity/ServerSideTrojan
Hmm. Let's say an object is owned by user Joe. I export the object and reimport it in a different Zope installation, where Joe doesn't exist. Who owns the object? nobody?
No - you do :) Importing is the moral equivalent of "creating" the object. Whenever you create, copy, cut & paste or import you will get ownership of the resulting new object. To me, the more hairy issue is what if Joe *does* exist in the different Zope installation, and you *do* want Joe to continue to have ownership? Currently, you must either arrange for Joe to do the import (which will give him ownership directly), or import it and use an external method to assign ownership (which is a pain). One thing we've thought of is that perhaps superuser (and only superuser) could be able to assign ownership through a web interface, which could make this sort of thing a bit easier. Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
Brian Lloyd wrote:
Hmm. Let's say an object is owned by user Joe. I export the object and reimport it in a different Zope installation, where Joe doesn't exist. Who owns the object? nobody?
No - you do :) Importing is the moral equivalent of "creating" the object. Whenever you create, copy, cut & paste or import you will get ownership of the resulting new object.
To me, the more hairy issue is what if Joe *does* exist in the different Zope installation, and you *do* want Joe to continue to have ownership?
Aie. I tend to import/export really big chunks of objects that would presumabley be owned by different people. So having one of the users import wouldn't be good enough. How about generating a unique id for each user that is also unique across Zope installs (as in ZClasses)? Then when importing you'd check if Joe here is the same Joe there by comparing the unique ids (which would be stored together with the zexp - no point in storing them in every object.) So you'd just have to make sure you importing acl_users before importing other objects, or set the user's unique id via some sort of web form. Of course, this wouldn't work for SQL and LDAP and passwd users. Or go the Unix way - if the username is the same, assume it's the same user (of course in Unix it's the uid, not the username, that counts). -- Itamar S.T. itamar@maxnm.com
Brian Lloyd wrote:
This release contains the new changes to the Zope security model to protect against the server-side trojan issue:
http://www.zope.org/Members/jim/ZopeSecurity/ServerSideTrojan
Hmm. Let's say an object is owned by user Joe. I export the object and reimport it in a different Zope installation, where Joe doesn't exist. Who owns the object? nobody?
No - you do :) Importing is the moral equivalent of "creating" the object. Whenever you create, copy, cut & paste or import you will get ownership of the resulting new object.
Any possibility for UNIX's su functionality (or BECOME USER in SQL) ------- Hannu
participants (3)
-
Brian Lloyd -
Hannu Krosing -
Itamar Shtull-Trauring