On Sunday 06 Oct 2002 4:56 pm, Chris McDonough wrote:
It's probably unavoidable that the log file is opened as root -- it's used to report "can't setuid()". :-)
Thats what syslog is for. It is good security practice that a daemon should *never* have a writeable file descriptor for its log file. If it does, and the daemon is compromised, an attacker can trivially cover his tracks by removing the incriminating evidence from the log file.
Pidfiles too.
Currently it is common practice for Zope's 'stop' scripts to be run as root. We cant allow the pid files to be written by non-root users, otherwise those users could trick root into killing an arbitrary process.
The only real purpose to running as root is to be able to bind to low-numbered TCP ports.
IMO there are better solutions to the problems to which low-numbered ports are a common solution. Zope/ZSS never *needs* a low numbered port, and zope should never be started as root. (I have cc'ed zope-dev. I suggest we continue there, rather than zodb-dev)
[Guido]
It's probably unavoidable that the log file is opened as root -- it's used to report "can't setuid()". :-)
[Toby]
Thats what syslog is for.
It is good security practice that a daemon should *never* have a writeable file descriptor for its log file. If it does, and the daemon is compromised, an attacker can trivially cover his tracks by removing the incriminating evidence from the log file.
Well, there goes zLOG's MinimalLogger implementation. (This only holds for log files owned by a root, right?) [Chris]
Pidfiles too.
Currently it is common practice for Zope's 'stop' scripts to be run as root. We cant allow the pid files to be written by non-root users, otherwise those users could trick root into killing an arbitrary process.
The current design, for whatever reason, writes the pidfile as *late* as possible. That's often bugged me, because there's a failure mode where the process dies before the pidfile is written; zdaemon restarts it over and over (that's what prompted my zdaemon hack proposal), and the stop script won't stop it. (And of course, being an very infrequent Zope user, I always forget how to set up the environment so that Zope will run correctly. Fortunately I never run it as root. :-)
The only real purpose to running as root is to be able to bind to low-numbered TCP ports.
IMO there are better solutions to the problems to which low-numbered ports are a common solution. Zope/ZSS never *needs* a low numbered port, and zope should never be started as root.
Correct.
(I have cc'ed zope-dev. I suggest we continue there, rather than zodb-dev)
I wish there were fewer lists. I can never decide which list is right. :-( --Guido van Rossum (home page: http://www.python.org/~guido/)
On Monday 07 Oct 2002 1:14 pm, Guido van Rossum wrote:
Well, there goes zLOG's MinimalLogger implementation.
The module name might be 'MinimalLogger', but everywhere else it is known as 'the stupid log'.
(This only holds for log files owned by a root, right?)
No, I dont think ownership is relevant. Any log file which the zope process can overwrite it of little use in proving that your zope process has not been compromised.
Pidfiles too.
Currently it is common practice for Zope's 'stop' scripts to be run as root. We cant allow the pid files to be written by non-root users, otherwise those users could trick root into killing an arbitrary process.
The current design, for whatever reason, writes the pidfile as *late* as possible. That's often bugged me, because there's a failure mode where the process dies before the pidfile is written; zdaemon restarts it over and over (that's what prompted my zdaemon hack proposal), and the stop script won't stop it.
There is a trick here - it writes two pid files. One is written by the server process (as you point out, this one is written very late), the other is written by the supervisor process immediately after forking. By default this is in var/zProcessManager.pid You should be able to send SIGTERM to the supervisor process, and it should pass it on to the server process. Ive only just discovered that: a. The signal forwarding doesnt seem to work for me b. The default stop script doesnt use this pid.
Well, there goes zLOG's MinimalLogger implementation.
The module name might be 'MinimalLogger', but everywhere else it is known as 'the stupid log'.
And stupid it is. But it's the only one we've got in the Zope core. :-(
(This only holds for log files owned by a root, right?)
No, I dont think ownership is relevant. Any log file which the zope process can overwrite it of little use in proving that your zope process has not been compromised.
Fair enough. But then why did you specifically refer to file descriptors?
Pidfiles too.
Currently it is common practice for Zope's 'stop' scripts to be run as root. We cant allow the pid files to be written by non-root users, otherwise those users could trick root into killing an arbitrary process.
The current design, for whatever reason, writes the pidfile as *late* as possible. That's often bugged me, because there's a failure mode where the process dies before the pidfile is written; zdaemon restarts it over and over (that's what prompted my zdaemon hack proposal), and the stop script won't stop it.
There is a trick here - it writes two pid files. One is written by the server process (as you point out, this one is written very late), the other is written by the supervisor process immediately after forking. By default this is in var/zProcessManager.pid
This is done by zdaemon, right? I think that ZEO at least disables this.
You should be able to send SIGTERM to the supervisor process, and it should pass it on to the server process. Ive only just discovered that:
a. The signal forwarding doesnt seem to work for me
b. The default stop script doesnt use this pid.
How typical. One problem here, as always, is that the conventions are undocumented, or at least not documented where I would look for the documentation. :-( --Guido van Rossum (home page: http://www.python.org/~guido/)
On Monday 07 Oct 2002 1:47 pm, Guido van Rossum wrote:
Well, there goes zLOG's MinimalLogger implementation.
The module name might be 'MinimalLogger', but everywhere else it is known as 'the stupid log'.
And stupid it is. But it's the only one we've got in the Zope core. :-(
For Zope there is the zLOG and ZLogger modules, which interact in mysterious ways. syslogLogger is in ZLogger. part of the mysterious plumbing is in z2.py, so is not available to a ZEO server.
(This only holds for log files owned by a root, right?)
No, I dont think ownership is relevant. Any log file which the zope process can overwrite it of little use in proving that your zope process has not been compromised.
Fair enough. But then why did you specifically refer to file descriptors?
It is possible for a log file to be owned by root and writeable only by root, yet still be open to compromise. This can happen if the file is opened by this process before dropping root privelidges, and never closed.
On Mon, Oct 07, 2002 at 07:39:05AM +0100, Toby Dickenson wrote:
On Sunday 06 Oct 2002 4:56 pm, Chris McDonough wrote:
It's probably unavoidable that the log file is opened as root -- it's used to report "can't setuid()". :-)
Thats what syslog is for.
Only issue with syslog is defining what facility to use and changing the code to use it. That and win32 support.
It is good security practice that a daemon should *never* have a writeable file descriptor for its log file. If it does, and the daemon is compromised, an attacker can trivially cover his tracks by removing the incriminating evidence from the log file.
+1 for syslog.
The only real purpose to running as root is to be able to bind to low-numbered TCP ports.
IMO there are better solutions to the problems to which low-numbered ports are a common solution. Zope/ZSS never *needs* a low numbered port, and zope should never be started as root.
Maybe better, but not simpler. It's the Unix standard to run daemons in low-numbered ports, and we know the reasons for it. I'd propose calling socket() and then setuid() (with the relevant save pid step), and then run the ZEO normally as the user using either a user-written log or syslog.
(I have cc'ed zope-dev. I suggest we continue there, rather than zodb-dev)
This is really a ZEO issue, as far as both Zope and standalone ZEO's affected, but anyway.. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL
Personally I use http://cr.yp.to/daemontools.html and it solved all these problems for me quite nicely. No more pid files, no more ownership problems, no more logging headaches. I think someone has a HowTo on setting up daemontools with z2.py/stupid logger, but I actually wrote my own logging module and replaced z2.py entirely with a 39 line python script that does nothing but pcgi (which is all I needed). I don't expect this to become a standard solution for all the usual reasons DJB's software never becomes a standard. But do take a look at the design behind it, its good stuff. (if anyone wants my start scritps or logger mail me off-list) -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue
participants (4)
-
Christian Reis -
Guido van Rossum -
Jamie Heilman -
Toby Dickenson