Behrens Matt - Grand Rapids wrote:
[snipped enlightening description of the zope user writable z2.pid problem]
Solutions:
1. Have the stop script check ownership of the pid file to make sure it's still root's baby. This solution seems easiest, but something about it doesn't seem right to me. When something doesn't feel right to me, there's probably a way to fool it...
2. Enforce the sticky bit on the var directory. From Solaris' chmod(2) manpage:
If a directory is writable and has S_ISVTX (the sticky bit) set, files within that directory can be removed or renamed only if one or more of the following is true (see unlink(2) and rename(2)):
o the user owns the file
o the user owns the directory
o the file is writable by the user
o the user is a privileged user
(Privileged user means 'root'.) We only need to enforce the sticky bit if we start as root and are doing the requisite setuid(). My patch already has a test for this.
3. Have the pid file written into another directory that only root can write to.
I don't like 1 either because it looks too complicated for a security issue solution. Security solutions should be extremely simple so that they can be made easily debugable and ... (/me looks at Zope security machinery source code)... never mind :-) Anyway, 3 looks more aesthetically pleasing to me, mainly because it requires the least amount of code, but I can live with number 2. Overall, I like the way you are going with this patch. Keep the good work :-) cheers, Leo