Anders Brander writes:
> Extra security? I've always hated the vpopmail model, "all users are one
It has advantages and disavantages. It means that vpopmail runs under
a dedicated user and group without (at the moment) any need for set-id.
IMAP and POP servers do need setuid root if they are to work for system
users and so I'd be more worried about them being compromised for root
privilege than them being compromised so that somebody could turn
himself into the vpopmail user and read other people's mail. I would
go so far as to say that on a system where all users have vpopmail-owned
mail and if the IMAP and POP3 servers were setuid vpopmail then you would
have more security not less because only the mail system is exposed if
somebody finds a hole (I'm not saying that somebody trashing mail is
desirable but it's better than them trashing the whole system including
> > Oh, unless you're using a PHP webmail
> There could be many other reasons to give domainmail-admins
> system-users. Admin'ing mailinglists for one.
I've never played with it, but qmailadmin appears to support ezmlm
mailing lists without needing system users.
> Yep, or maybe the biggest feature. But hey, qmail is delivering to
> systemusers isn't it? vdeliver doesn't even get run?
As I understand things. But I have never looked too deeply into that.
We don't have system users in the traditional sense. Clients have
user accounts for FTP to their web sites but do not have shell access.
Although we have a few admins as system users that's only so they can
su root when necessary, their mail is handled through a virtual domain
just like our customers. We don't have people who log into our servers
to read mail in between playing nethack or whatever.
> But theres much more to it than buffer overflows. How do we trust the
> calling program, for one thing?
You don't trust the calling program. You ensure that the directory
these utilities are in is rx only to vpopmail:vchkpw. If somebody
can su to those or insert a malicious program into ~vpopmail/bin and
get it executed then you have more problems than a calling problem
passing something weird. Those risks are present in the current model
anyway, so adding these utilities does not make matters worse.
If somebody can make a calling program maliciously call the database
modify utility to wipe out arbitrary users they can do so under the
current model too. The only thing these utilities would be doing
in addition to what is currently done is providing a way of hiding
the MySQL password. Essentially you would be extracting a few functions
from libvpopmail, putting them into separate programs and adding
the "get MySQL password" stuff to those additional programs. I don't
see that this imposes an additional risk provided those additional
programs are kept small and written well. Compared to having the
password wired into libvpopmail.a, it is a significant improvement...
I suppose we could always look how Courier does it to see if there's a
better way, but that's cheating.