zope 2.3.0 upgrade bug: inituser trashes existing user
I have not thoroughly tested this, but I have done it twice to make sure I could reproduce the error I saw in the specific circumstances I saw it. I suspect the bug is generic, but don't have the time to prove it right now. My setup: INSTANCE_HOME style setup. Zpatterns installed in 2.3.0 tree EMarket installed in the instance products folder. RedHat Linux 5.2 (I think, how do you tell on a linux system?) python from RPMs, zope 2.3.0 from source install (wo_pcgi). I upgraded an existing site by simply changing my zopectl (see my product) PYTHONHOME setting to the 2.3.0 tree, shutting down the site (which had been running 2.2.4), and restarting. Now, at this point I did not understand how inituser was supposed to work, so I had copied my old access file to be my inituser file, thinking the name had changed but the semantics were similar. Imagine my surprise when the inituser file dissapeared when I started zope <grin>. The problem is that the inituser *replaced* the single existing user in the acl_users folder. This must be a bug. --RDM PS: I also was amazed to find that having ZDebug (without Chris' patch) in my Products folder left my site *wide* open: anonymous could view and edit methods. This might be worth a warning on the web site, even though it is unlikely anyone would run production with ZDebug installed.
Zope mailing lists wrote:
The problem is that the inituser *replaced* the single existing user in the acl_users folder. This must be a bug.
Nope, it's intentional. Think about this scenario: you install Zope for the first time by running the install script. You see a lot of messages but you let them all scroll by. You enter "./start". You visit localhost:8080 and see the link to the management screen. You click it and it asks for a user name and password. You try your login password, the root password, and a few others, but nothing works. You read the instructions further. Ah, you should have paid attention to those messages. But there's a documented way out: python zpasswd.py inituser Problem solved. When the "inituser" concept was first created, this solution did not work. It would only populate the root user folder if there were no existing users. This led to lockouts. In the current release, if inituser is found and there are zero or one users in the root folder, it clears the user database and adds the one user, then tries to delete inituser. However, to deal with the train of thought which you encountered (which is inaccurate but understandable), perhaps it should never clear the database and instead add one user if that user is not already present. OTOH it would still not give you what you wanted. The "access" file still exists and serves the same purpose as it did before. However, it is no longer mandatory that it exist. The inituser file is designed to set up only the initial manager then never run again.
PS: I also was amazed to find that having ZDebug (without Chris' patch) in my Products folder left my site *wide* open: anonymous could view and edit methods. This might be worth a warning on the web site, even though it is unlikely anyone would run production with ZDebug installed.
The current version of ZDebug doesn't work because the signature of the validate() method in security policies changed, resulting in chaos. :-) I would agree it's unwise to run ZDebug on a production site simply because it reveals too much sometimes, such as exposing DTML source and the exact reason why a security assertion failed. Shane
participants (2)
-
Shane Hathaway -
Zope mailing lists