[Zope-Coders] new zLOG

Chris McDonough chrism@zope.com
27 Nov 2002 10:34:47 -0500


On Wed, 2002-11-27 at 09:49, Toby Dickenson wrote:
> The fundamental problem with the stupid log is that the log file is opened by 
> the same process which generates the log events. There are several solutions, 
> but all involve adding an additional process to perform the writing to file. 
> For security it is important that this new process is not running as the same 
> user id as the zope process.

OK, sorry to be dense, but why is the process owner being different than
the zope user so important from a security standpoint?

> I am not sure which option is the right default for Zope, but we could choose 
> from:
> 
> 1. Zope writes log enties to stdout, and the default start script pipes that 
> into a new process which writes it to a file. If started as root, this new 
> process would need to suid itself.
> for:
> 	easy to explain.
> 	zero admin overhead
> against: 
> 	you cant have more than one log managed this way.
> 	does not work securely unless zope is started as root.
> 
> 2. Zope creates a pipe, then forks a new process. Zope writes log entries to 
> the pipe. The new process reads events from the pipe, and writes them to a 
> file.
> for:
> 	zero admin overhead
> 	supports multiple log files
> against:
> 	does not work securely unless zope is started as root.
> 
> 3. Zope sends log entries to some kind of external socket (unix, udp, and tcp 
> all make sense). A different process listens on that socket, and writes to a 
> file. Note that Zope could fork this process itself (but this is secure only 
> when started as root), or it could be started externally.
> for:
> 	zero admin overhead when started as root
> 	can be secure even when not started as root with a little admin overhead.
> 	supports multiple log files
> against:
> 	possibly lower performance
> 	complexity

Since file-logging is the lowest-common-denominator across platforms,
it's likely going to be the default.  Since it's going to be the
default, it needs to work predictably, so ignoring the setuid problem
doesn't seem to be an option.  Your options above (aside from 3, which
is syslog) seem to be kinda complicated.  Wanting to write a file-based
log as an effective user when started as root seems like a fundamental
problem in UNIX daemon applications.  

I looked at the Apache and Squid sources to see how they do it, and as
far as I can tell they take the "log to stderr until after some point
after minimal startup" tact.  I'm still not sure why we can't do the
same without all the complexity you describe above.

I'm not saying "you're wrong and I'm right", I maybe just need to
understand better what is so terrible about that solution, besides your
distaste for file-logging in general.

- C