[37 lines snipped]
: :qmail uses a set-uid posting program, called qmail-queue. When
: :this program is invoked, it opens a queue file somewhere below
: :/var/qmail/queue. For example:
: :
: : -rw-r--r-- 1 qmailq qmail 0 Dec 31 17:02 queue/mess/21/674956
: :
: :What happens when the qmail-queue process is signaled with, say,
: :SIGKILL? The file will stay in the queue. That's a zero-length
: :file, owned by qmail, without any user identification whatsoever.
: :
: :Each time a user does something like:
: :
: : % /var/qmail/bin/qmail-queue
: : ^Z
: : Suspended
: : % kill -9 %1
: : [1] Killed /var/qmail/bin/qmail-queue
: : %
: :
: :There will be one more zero-length file, owned by qmail, without
: :any user identification whatsoever. It is an exercise for the
: :reader to write a small program that automates the process:
[34 lines snipped]
It's hardly in the same league as the postfix design oversight.
This one prevents new mail being queued, that one causes mail
to disappear after it has entered the responsibility of the mta.
Still I wonder:
1) Why does qmail-queue employ a sequence number, since no two
processes can have the same pid? If the pidfn is unique to the pid,
then it's a simple matter to open it O_TRUNC rather than O_EXCL.
Then the number of junk files is limited to sizeof pid_t.
2) Why does qmail-queue link the mess file in before the message
is written? Because a bad mess file isn't cleaned up but every
36 hours, whereas a bad pid file will be reclaimed every time the
pids roll around.
3) Why not write the uid into a Received: line automatically?
4) Could setuid(geteuid()) but that doesn't buy very much.
None of this prevents a DOS attack.
-harold
