Commit 0d230940 authored by Chris McDonough's avatar Chris McDonough

Update for 2.7.

parent 96f70233
ZServer 'setuid()' support Zope effective user support
ZServer (Zope's server) supports 'setuid()' on POSIX systems in order to Zope can bind its network service to low ports such as 21 (FTP) and
be able to listen on low ports such as 21 (FTP) and 80 (HTTP) but drop 80 (HTTP). In order to bind to low ports, Zope must be started as
root privileges when running; on most POSIX systems only the 'root' user the root user. However, Zope will only run as root long enough to
can do this. Versions of Zope prior to 2.6 had less robust versions bind to these low ports. It will then attempt to setuid to a less
of this support. Several problems were corrected for the 2.6 release. privileged user.
The most important thing to remember about this support is that you You must specify the user to which Zope will attempt to setuid by
don't *have* to start ZServer as root unless you want to listen for changing the 'effective-user' parameter in the zope.conf
requests on low ports. In fact, if you don't have this need, you are configuration file to an existing username or UID. All runtime
much better off just starting ZServer as a user account dedicated to files will be written as this user. If you do not specify an
running Zope. 'nobody' is not a good idea for this user account; 'effective-user' in the configuration file, and you attempt to start
see below. Zope, it will refuse to start.
If you do need to have ZServer listening on low ports, you will need to Zope additionally emits a warning if you specify 'nobody' as the
start 'z2.py' as the 'root' user, and also specify what user ZServer 'effective-user'. The rationale for this warning stems from the
should 'setuid()' to. Do this by specifying the '-u' option followed fact that, historically, many other UNIX services dropped privileges
by a username or UID, either in the 'start' script or on the 'z2.py' to the 'nobody' account after starting as root. Any security
command line. The default used to be 'nobody'; however if any other defects in these services could cause someone to gain access as the
daemon on a system that ran as 'nobody' was compromised, this would 'nobody' account on your system. If someone was to gain control of
have opened up your Zope object data to compromise. your 'nobody' account they could compromise your Zope files.
You must also make sure the var directory is owned by root, and that The most important thing to remember about effective user support is
it has the sticky bit set. This is done by the command 'chmod o+t that you don't have to start Zope as root unless you want to listen
var' on most systems. When the sticky bit is set on a directory, for requests on low ports (ports beneath 1024). In fact, if you
anyone can write files, but nobody can delete others' files in order don't have this need, you are much better off just starting Zope
to rewrite them. This is necessary to keep others from overwriting under a dedicated user account.
the PID file, tricking root into killing processes when 'stop' is run.
...@@ -4,32 +4,23 @@ Signals (POSIX only) ...@@ -4,32 +4,23 @@ Signals (POSIX only)
If you are using Windows then this documentation does not apply. If you are using Windows then this documentation does not apply.
Zope responds to signals which are sent to the process id Zope responds to signals which are sent to the process id
specified in the file 'ZOPE_HOME/var/Z2.pid':: specified in the file '$INSTANCE_HOME/var/Z2.pid'::
SIGHUP - close open database connections, then restart the server SIGHUP - close open database connections, then restart the server
process. The common idiom for restarting a Zope server is: process. A idiom for restarting a Zope server is:
kill -HUP `cat ZOPE_HOME/var/z2.pid` kill -HUP `cat $INSTANCE_HOME/var/z2.pid`
SIGTERM - close open database connections then shut down. The common SIGTERM - close open database connections then shut down. A common
idiom for shutting down Zope is: idiom for shutting down Zope is:
kill -TERM `cat ZOPE_HOME/var/Z2.pid` kill -TERM `cat $INSTANCE_HOME/var/Z2.pid`
SIGINT - same as SIGTERM SIGINT - same as SIGTERM
SIGUSR2 - close and re-open all Zope log files (z2.log, event log, SIGUSR2 - close and re-open all Zope log files (z2.log, event log,
detailed log.) The common idiom after rotating Zope log files detailed log.) A common idiom after rotating Zope log files
is: is:
kill -USR2 `cat ZOPE_HOME var/z2.pid` kill -USR2 `cat $INSTANCE_HOME/var/z2.pid`
The process id written to the 'z2.pid' file depends on whether Zope
is run under the 'zdaemon' management process. If Zope is run under
a management process (as it is by default) then the pid of the
management process is recorded here. Relevant signals sent to the
management process are forwarded on to the server process.
Specifically, it forwards all those signals listed above, plus
SIGQUIT and SIGUSR1. If Zope is not using a management process (-Z0
on the z2.py command line), the server process records its own pid
into 'z2.pid', but all signals work the same way.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment