FrontPage UserBootstrapping / backlinks

UserBootstrapping Proposal

Note - this document is still a work in progress. Please do not make inline comments in the proposal - use the UserBootstrappingDiscussion to make comments.

Contact

Brian Lloyd (brian@digicool.com)

Problem

As of Zope 2.2, the behavior (and to some extent, the meaning) of the superuser created at Zope installation time has changed. The intent was always that a Zope user would install the software, log in as the superuser, create a management user and then use that management user for further operations. The idea was that the superuser was an all-powerful user that should only be used in emergencies to recover from situations that required it. As of 2.2, a restriction was added in regard to the superuser: the superuser is not allowed to own objects in the new security model. This is consistent with the idea that use of the superuser login is for emergency puposes only.

Feedback from the 2.2 release shows pretty clearly though that a number of people in fact login and begin trying to do work as the superuser. We have gotten many reports from people complaining of Super cannot own errors, because they are logging right in with the superuser, trying to create objects, etc. People new to Zope especially argue that this is unintuitive behavior; a superuser should be all-powerful shouldn't he? This also means that newbies who try to jump in and "learn by doing" by either using the tutorial or experimenting will usually run into an immediate stumbling block and get a bad first impression of Zope.

A second and somewhat related problem is that some people want to implement top-level UserFolder^x objects that may incorporate "executables" that respect ownership. Because the superuser cannot own objects, it is hard to build things based on components like LoginManager^x as the top level UserFolder^x (because you'll need to create things that want to be owned).

Proposed Solution

This project proposes to revisit the way that "bootstrapping" of users in Zope is done, making it far more intuitive and immediately useful than it is now.

• At install time, you would still create a bootstrap user login, but that user would not be the thing that we currently think of as the superuser. It would be an initial manager user. When you first login with this user, you can go ahead and start doing things, use the tutorial, etc.

• The thing that we currently think of as the superuser would not even exist by default. Because it is only for dire emergencies, it can be created via a command-line script (similar, but separate from the existing zpasswd.py script) if it is ever needed. This has the added security benefit that there isn't even a superuser login around to be abused unless you explicitly create it. It should also be possible to get rid of the superuser login again when you are done with it. We should probably start referring to this as the emergency user or something to make its role totally clear.

Risk Factors

• Backward compatibility seems like the only real problem. We will need to figure out how to deal with existing installations.

Scope

This project would supercede the proposals to expand the access file to create more special users. The scope is limited to:

• allowing users to bootstrap a single user that they can do real work with (no more 2-step process)

• supporting the creation and use of an emergency user for situations where it is required

Deliverables

This project is expected to produce:

• Changes to the bootstrapping machinery to generate and install an initial manager user

• A facility for enabling or defining (and disabling) the emergency user on an as-needed basis.

• Updated installation documentation that reflects these changes, as well as documentation for recovering from situations using the emergency user.