Hi Anders Anders Brander writes:
> Extra security? I've always hated the vpopmail model, "all users are one > user" 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 mail).. > > Oh, unless you're using a PHP webmail > [snip] > > 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. -- Paul Allen Softflare Support
