>There appears to be a possible problem in the imap/pop3 daemon shipped
>with (at least) redhat version 4.2. While I don't have the time to
>research it fully, a world-writable PID file is probably not a good
>thing.. even if the daemon is running as the user id checking mail..
>Perhaps someone with more time can check into it.
This is a problem in that you can probably make pine (etc) unaware that
another process is running by putting a junk PID in the PID file, however
it's not the main problem with these lockfiles. Since they have
predictable filenames based on the file which they're locking, and are
made in /tmp, there's an easy DoS to lock out one user from reading email.
This is actually a bit of a problem with the pine (etc) generic c-client
libraries, viz:
[as a user other than the user in question; wait for them to start pine
(or similar]
tartarus; cd /tmp
tartarus; ls -ld .?*.*
-rw-rw-rw- 1 demo ucs 3 Jul 15 18:12 .803.58e00
[note: this filename is .[devicemajor<<8+deviceminor].[inode] in hex]
[wait for pine/imap4d/pop3d/whatever to finish]
tartarus; echo '1' >/tmp/.803.58e00
The folder is now opened read-only in pine/imap4d/pop3d (etc) since it
can't create a lockfile for it (note that this is using the "bezerk"
driver in the c-client libraries, the default driver for reading
BSD-format mailboxes, as used by most sites; we use the tenex2 driver for
most users here which doesn't leave these .xxx.xxxx files around for the
whole pine or imap4 session, but if you look at the device and inode
numbers of the BSD-format mailbox the mail is being grabbed from into the
tenex-format mailbox it still works). Of course, you can find the user who
does this and persecute them (assuming they can't find another security
hole to create files in someone else's name) but the hole is still there.
While my fix for this DoS attack is called "removeuser" (of the offender)
and fixing other security holes which would allow people to create files
in /tmp with someone else's name on them, a "better" fix would be nice -
for example the lockfile for the BSD-format inbox could be stored in the
user homedirectory, this only looses where mailboxes are hardlinked or
symlinked (and sane MTAs won't deliver to them anyway).
David.