[Zope-dev] zope 2.3.0 upgrade bug: inituser trashes existing user

[Shane Hathaway]

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