ownership fun and games.
So we had a couple of people who'd been working on zope here leave, and their user objects got deleted. Stuff starts breaking _everywhere_, because the permissions of a zope object are the intersection of the permissions of the owner and the permissions of the user -- no owner means an intersection with the null set. Oops. The following external method and python script will help you if something similar ever happens to you. This Python Script will find objects owned (explicitly) by non-existent users and set the ownership to the person running the script. ---------------8<------------------------8<------------------- # Change these two. The first is where to start looking, the second is the # acl_users folder to check. top = container.ekorp users = container.acl_users.getUserNames() u={} for i in users: u[i] = 1 isUser = u.has_key todo = [top] while 1: if not todo: break next,todo = todo[0], todo[1:] for id, obj in next.objectItems(): try: owner = obj.owner_info() except: continue if owner['explicit']: user = owner['id'] if not isUser(user): print "/".join(obj.getPhysicalPath()), owner['explicit'], user container.fixownership(obj) if hasattr(obj, 'objectItems') and obj.objectItems(): todo.append(obj) return printed ---------------8<------------------------8<------------------- There's also an external method needed - install it as "fixownership" in the same folder as the object pythonscript. (aside: This is only needed because of the idiotic checks on HTTP referrer in AccessControl/Owned.py Owned.manage_takeOwnership(). Fine, you want more security. Almost nothing else in Zope does this sort of checking - why this one method?? As it is, the interface may as well not be there - it's unusable programmatically.) ---------------8<------------------------8<------------------- def fixownership(object): from AccessControl import getSecurityManager user=getSecurityManager().getUser() object.changeOwnership(user) ---------------8<------------------------8<------------------- Hopefully this will be of use to someone, somewhere. Anthony
Anthony Baxter wrote:
So we had a couple of people who'd been working on zope here leave, and their user objects got deleted.
That wasn't a good idea ;-) Much better to just set their passwords to something random...
The following external method and python script will help you if something similar ever happens to you. This Python Script will find objects owned (explicitly) by non-existent users and set the ownership to the person running the script.
Cool :-) cheers, Chris
Chris Withers wrote Anthony Baxter wrote: So we had a couple of people who'd been working on zope here leave, and their user objects got deleted.
That wasn't a good idea ;-) Much better to just set their passwords to something random...
That's a pragmatic approach, sure. But it sucks arse as a general rule. There should be an easy way to remove old users entirely, without having the system becoming completely insane. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony Baxter wrote:
Chris Withers wrote
Anthony Baxter wrote:
So we had a couple of people who'd been working on zope here leave, and their user objects got deleted.
That wasn't a good idea ;-) Much better to just set their passwords to something random...
That's a pragmatic approach, sure. But it sucks arse as a general rule.
Not if you have any kind of need for an audit trail. You want to know who did what, and when. The approach I suggested is particularly handy as you get a transaction entry when yo ureset their password, so you can tell when they should have stopped doing things ;-) cheers, Chris
Chris Withers wrote Not if you have any kind of need for an audit trail. You want to know who did what, and when. The approach I suggested is particularly handy as you get a transaction entry when yo ureset their password, so you can tell when they should have stopped doing things ;-)
Nope, sorry, doesn't work for me. If you can't safely delete a user, then a) the 'delete' button should be removed from the acl_users tab b) an alternate 'retire' option should be created. "Just change the password" is not a particularly safe or sane way to do things. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony Baxter wrote:
Chris Withers wrote
Not if you have any kind of need for an audit trail. You want to know who did what, and when. The approach I suggested is particularly handy as you get a transaction entry when yo ureset their password, so you can tell when they should have stopped doing things ;-)
Nope, sorry, doesn't work for me. If you can't safely delete a user, then a) the 'delete' button should be removed from the acl_users tab b) an alternate 'retire' option should be created.
"Just change the password" is not a particularly safe or sane way to do things.
Well, ideally there should be both a 'delete' and 'retire' button (I'd prefer to call it 'disable') but given that the current functionality makes it easier to make the disable button function without bugs, I reckon that'd be the way to go. If you write and proposaland drag it through the fishbowl, I'd be happy to do the coding... cheers, Chris
Chris Withers wrote:
Anthony Baxter wrote:
So we had a couple of people who'd been working on zope here leave, and their user objects got deleted.
That wasn't a good idea ;-) Much better to just set their passwords to something random...
It would be much better if the user folder allowed to disable the user (something random could be eventually guessed, besides you'd have an indication that the user is inactive/old/obsolete/whatever). BTW: there are other cases that make removing old users impractical besides permission problems (think about workflow history, cmf metadata, etc.) Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, May 12, 2003, at 05:43 PM, Luca Olivetti wrote:
Chris Withers wrote:
Anthony Baxter wrote:
So we had a couple of people who'd been working on zope here leave, and their user objects got deleted. That wasn't a good idea ;-) Much better to just set their passwords to something random...
It would be much better if the user folder allowed to disable the user (something random could be eventually guessed, besides you'd have an indication that the user is inactive/old/obsolete/whatever).
BTW: there are other cases that make removing old users impractical besides permission problems (think about workflow history, cmf metadata, etc.)
And if they are relying on the user object to remain around for ever, they are broken IMHO. Consider the user folder that is populated from an external source such as a company's LDAP server. - -- Stuart Bishop <zen@shangri-la.dropbear.id.au> http://shangri-la.dropbear.id.au/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+wOOqh8iUz1x5geARAmP4AKDhNxWjyq5IGykNQZSSGl6kyFriPgCcCgpM 3W6pCRQ1gLDN7du0JXb6csU= =DQyG -----END PGP SIGNATURE-----
On Tuesday, May 13, 2003, at 08:23 AM, Stuart Bishop wrote:
It would be much better if the user folder allowed to disable the user (something random could be eventually guessed, besides you'd have an indication that the user is inactive/old/obsolete/whatever).
BTW: there are other cases that make removing old users impractical besides permission problems (think about workflow history, cmf metadata, etc.)
And if they are relying on the user object to remain around for ever, they are broken IMHO. Consider the user folder that is populated from an external source such as a company's LDAP server.
Typically, a deleted user is either assigned to the administrator, or the admin is given the option of re-assigning those items to a different user. Either way, ownership is not broken, and a log can be preserved of this re-assignment for cases where such archiving is needed. ___/ / __/ / ____/ Ed Leafe http://leafe.com/ http://opentech.leafe.com
+-------[ Ed Leafe ]---------------------- | On Tuesday, May 13, 2003, at 08:23 AM, Stuart Bishop wrote: | | >>It would be much better if the user folder allowed to disable the | >>user (something random could be eventually guessed, besides you'd | >>have an indication that the user is inactive/old/obsolete/whatever). | >> | >>BTW: there are other cases that make removing old users impractical | >>besides permission problems (think about workflow history, cmf | >>metadata, etc.) | > | >And if they are relying on the user object to remain around for ever, | >they are broken IMHO. Consider the user folder that is populated | >from an external source such as a company's LDAP server. | | Typically, a deleted user is either assigned to the administrator, | or the admin is given the option of re-assigning those items to a | different user. Either way, ownership is not broken, and a log can be | preserved of this re-assignment for cases where such archiving is | needed. This can't happen if the users come from some external source and are managed outside of Zope. If the external source doesn't allow browsing of the user list, you can be royally screwed, since you can't detect the situation either. Since Zope allows you to build permission lists that explicitly exclude 'Manager', you can find yourself in a pretty bad state. There are ways around this even for externally managed user sources. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | M:+61 416 022 411 | ACN: 082 081 472 ABN: 83 082 081 472 |akm@theinternet.com.au| Carpe Daemon
Sorry for my naive question (newbie one's, I'm afraid), would not be possible to set a special role for a user in charge of taking ownership of all the abandonned stuff ? Andrew Kenneth Milton wrote:
+-------[ Ed Leafe ]---------------------- | On Tuesday, May 13, 2003, at 08:23 AM, Stuart Bishop wrote: | | >>It would be much better if the user folder allowed to disable the | >>user (something random could be eventually guessed, besides you'd | >>have an indication that the user is inactive/old/obsolete/whatever). | >> | >>BTW: there are other cases that make removing old users impractical | >>besides permission problems (think about workflow history, cmf | >>metadata, etc.) | > | >And if they are relying on the user object to remain around for ever, | >they are broken IMHO. Consider the user folder that is populated | >from an external source such as a company's LDAP server. | | Typically, a deleted user is either assigned to the administrator, | or the admin is given the option of re-assigning those items to a | different user. Either way, ownership is not broken, and a log can be | preserved of this re-assignment for cases where such archiving is | needed.
This can't happen if the users come from some external source and are managed outside of Zope. If the external source doesn't allow browsing of the user list, you can be royally screwed, since you can't detect the situation either.
Since Zope allows you to build permission lists that explicitly exclude 'Manager', you can find yourself in a pretty bad state.
There are ways around this even for externally managed user sources.
participants (7)
-
Andrew Kenneth Milton -
Anthony Baxter -
Chris Withers -
danielle -
Ed Leafe -
Luca Olivetti -
Stuart Bishop