[Web-SIG] Daemon server management

[Jacob Smullyan]

On Fri, Jun 10, 2005 at 10:55:47AM -0500, Ian Bicking wrote:
> >I think that if the pid file exists in any form, you are right to
> >refuse to start, with an error message about the pid file already
> >existing.  But if this is a separate test, you could still clobber one
> >a moment later when you write one yourself; so a careful open is
> >probably the most important thing.
> 
> I don't like this way of working -- a stale pid file should be 
> overwritten automatically.  Otherwise the admin has to figure out 
> whether the pid file wasn't cleaned up properly, or the server really is 
> alive.  The server can figure that out just as well as the admin can 
> manually (probably better).  Though some cases are ambiguous, e.g., you 
> can't be sure the live process is the same process that created the pid 
> file.

Although in that case, you'd refuse to start anyway and the admin
would have to figure out the situation; not an incorrect behavior.  

I agree, nothing wrong with checking whether the pid in an existing
file corresponds to a process and overwriting it if it doesn't -- at
least log that you are doing so, though.  In the case of a forking
server, this really doesn't matter much, because the papa proc of a
forking server crashes so rarely.  (I have never ever seen skunkweb
crash, for instance, even when I was using pygresql and its children
segfaulted every few minutes.)

> >As for log files, I *think* that they end up belonging to root even if
> >the child processes setuid to a nobody-style person.  That is what
> >I've done.  That seems to be what apache does.
> 
> Yes, I think that is the case.  But I think the group ownership might 
> change?

I see my apache logs owned by root:root.  And this makes sense,
actually; if the group changed, someone else might be able to write to
the file and that could be bad.

From the apache security tips page:

   If you allow non-root users to modify any files that root either
   executes or writes on then you open your system to root
   compromises. For example, someone could replace the httpd binary so
   that the next time you start it, it will execute some arbitrary
   code. If the logs directory is writeable (by a non-root user),
   someone could replace a log file with a symlink to some other
   system file, and then root might overwrite that file with arbitrary
   data. If the log files themselves are writeable (by a non-root
   user), then someone may be able to overwrite the log itself with
   bogus data.

[http://httpd.apache.org/docs-2.0/misc/security_tips.html]

> I generally like how Apache works now, since they've combined httpd and 
> apachectl, but I'm not sure how easy it would be for me to discover the 
> particulars.

The 2.0 source intimidates me a bit, because of the growth of the
codebase, apr, and the various worker modules.  The 1.3 source is
easier to navigate, although probably not to maintain, because of the
maze of #ifdefs.

j

-- 
Jacob Smullyan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/web-sig/attachments/20050610/ea91c425/attachment.pgp