Brian Lloyd wrote:
> > > > I notice there were some CVS checkins about renaming it to the
> > > > 'emergency user'. Cool, does this mean you're going to be
> > able to define
> > > > a manager at install-time?
> > >
> > > Yes - the whole lame login-as-superuser-create-a-manager-and-relogin
> > > process will be gone in 2.3. At install time you'll create a first
> > > manager and just use that.
> >
> > Yay!
> >
> > As Max asked, any 2.3 timeframe? Python Scripts and no Super User alone
> > make it _very_ enticing :-))
> I would reeeeeaaally like to see a beta by the end of
> Dec. - but don't quote me yet. Part of what I'm doing
> today is figuring what the resource situation looks like.
> > > He can un-screw permissions or users if you ever manage to
> > > get totally locked out of your site. Think of it as a user mounted
> > > in a box on the wall labeled "in case of emergency, break glass".
> >
> > How does this differ from a normal manager and how would you 'create a
> > super user' as you descriebd in the bit I snipped?
> An example might be: if somehow someone took all permissions
> away from all of your managers, they'd be out of luck. The
> superuser could still log in and fix that though.
> I don't know the exact details of how a superuser is created
> yet - I expect that you will run with a special
> option though (and restart). The relevant install docs will
> be updated to outline this when that branch is merged.

Here's how it is implemented right now.  The details could change if
someone can see any holes.

When Zope is started, there is already some initialization code that
gets run and has the opportunity to modify the ZODB if necessary.  A
procedure has been added that allows the root user folder to set up the
initial user.

If there are no users listed in the root user folder, it checks for a
file named "inituser" which has the same format as the "access" file. 
If found, it adds that user and tries to delete "inituser".  If, on the
other hand, there is already at least one user, the code that checks for
"inituser" is never executed.

The file named "access" now defines the emergency user.  It is no longer
required to exist--if it doesn't exist, no one can log in as the
emergency user.

Creating the emergency user or the initial user is easily done with the script.  You use it just as before.  The only difference is
that calls a method which generates "inituser" rather than

So, to create an emergency user, execute:

  python access

Or to create the inital user, execute:

  python inituser

The Windows installer is an unfinished detail: there's a script that
executes "python access".  It needs to execute "python inituser" instead.

There will be some problems with alternate user folders.  They expect to
be able to call methods on the SpecialUsers.super object.  When there is
no emergency user, the value of SpecialUsers.super is None.  The quick
solution is to create an emergency user.  The long-term solution is to
fix the user folders.


Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to