[ZODB-Dev] ZEO signal feature

[Guido van Rossum]

> > > > > Note that it only *starts* as root, and drops back to normal
> > > > > privs if you use runzeo with the -u switch.
> > > >
> > > > Yes, but it still drops root privelidges a little too late for
> > > > my liking. Both ZEO and Zope open log files as root, and Zope
> > > > (but not ZEO) even opens the storage as root.
> > >
> > > Can this be changed, though?
> >
> > It's probably unavoidable that the log file is opened as root --
> > it's used to report "can't setuid()". :-)
> 
> This message should probably go to stdout or stderr.

Unclear.  It seems that stdout+stderr are effectively ignored because
of the way zdaemon works.  (I played with zdaemon yesterday and found
that zdaemon throws aways stdout+stderr, so the only place you can see
even the most basic tracebacks is in the logs.

> The logfile should be opened as the effective user.  Pidfiles too.

No argument there.  Just the observation that it's tricky to open and
bind the socket earlier than the logfile, given how the code is
structured, at least in ZEO: the order of execution is something like

 1. open logfile
 2. setuid(nobody)
 3. open storage(s)
 4. create storage server, passing the storages

The storage server creates and binds the socket.  Fixing this would
require some significant restructuring of ZEO: the socket is actually
opened by asyncore, in a subclass of of asyncore.dispatcher.  At least
three software layers would have to be changed in order to open and
bind the socket before calling setuid().

> The only real purpose to running as root is to be able to bind to
> low-numbered TCP ports.  I've been trying to get the time to fix
> this in Zope as well.

In practice ZEO is never used with a low-numbered port AFAIK.  So why
do we run ZEO as root at all?  Perhaps ZEO should set the uid
immediately upon starting -- that avoids the restructuring I mentioned
above.

--Guido van Rossum (home page: http://www.python.org/~guido/)