A couple of days ago, I was investigating an obscure permissions problem
on a client's production server (having tried and failed to reproduce it
on the staging server). The problem was related to the creation of Ezmlm
mailing lists through a web interface (the details aren't relevant here,
nor especially interesting).
I tracked down and eventually fixed the problem by manually creating a
test list using ezmlm-make(1). Afterwards, I wanted to get
rid of the junk list, so I looked in the ezmlm command directory for the
opposite of ezmlm-make.
$ ls /usr/local/bin/ezmlm
ezmlm-accept ezmlmglrc ezmlm-moderate ezmlm-store
ezmlm-archive ezmlm-idx ezmlmrc ezmlm-sub
ezmlm-check ezmlm-issubn ezmlm-reject ezmlmsubrc
ezmlm-clean ezmlm-limit ezmlm-request ezmlm-tstdig
ezmlm-cron ezmlm-list ezmlm-return ezmlm-unsub
ezmlm-gate ezmlm-make ezmlm-rm ezmlm-warn
ezmlm-get ezmlm-manage ezmlm-send ezmlm-weed
ezmlm-glconf ezmlm-mktab ezmlm-split
ezmlm-rm looked promising, so I ran it without arguments to
get a usage message (which is how all the other ezmlm commands behave).
$ /usr/local/bin/ezmlm/ezmlm-list
ezmlm-list: usage: ezmlm-list [-mMnNvV] dir
$ /usr/local/bin/ezmlm/ezmlm-rm
$
Silence? That's not what I expected at all. What was it doing? I looked
a little closer.
$ man ezmlm-rm
No manual entry for ezmlm-rm
$ file /usr/local/bin/ezmlm/ezmlm-rm
/usr/local/bin/ezmlm/ezmlm-rm: Bourne shell script text executable
$ cat /usr/local/bin/ezmlm/ezmlm-rm
#!/bin/sh
rm -rf /home/vpopmail/domains/client.example.org/$1
rm -rf /home/vpopmail/domains/client.example.org/.qmail-$1*
A moment later, the sinking feeling set in when I realised that my
argument-less invocation had given the script an empty $1,
and what that actually meant for the dozens of lists that were stored
under vpopmail:
$ ls /home/vpopmail/domains
$
It turns out that the previous maintainer of the system—who disappeared
some time ago—saw nothing wrong with unchecked rm -rfs in a
script disguised as an ezmlm command.
Sigh.