Hi, On Thu, 2003-09-11 at 22:47, Tom Collins wrote: > On Thursday, September 11, 2003, at 01:22 PM, Ken Jones wrote: > > The issue about sql login being compiled in also brings up > > another issue.. By putting the sql information into > > a ~vpopmail/etc file it solves the issue as long as all > > email domains are owned by vpopmail. If any domains > > are under a non-vpopmail user, then the sql information > > file needs to be readable by all. In that case I would > > recomend not allowing shell access, and chrooting > > ftp access to a users home directory. > This is an interesting point and I'd love to find a clean solution to > this issue.
Me too, have been thinking about it for long time now (not getting much closer to a solution) > Are you saying that it's possible to run some of the vpopmail utilities > as a user other than root or vpopmail? I figured that for the > add/del/mod domain commands, you'd have to be root since they modify > qmail control files. When running vchkpw on a system that uses cdb, it > needs read access to the vpasswd file in the domain directory. qmail setuids/setgids to the user/group in /var/qmail/users/assign. I see three solutions... Possibly many more :) 1) More finegrained mysql-permissions. vedelivermail can only read what it's supposed to know. Should not be able to write to anything but log, from which it can't read (like the syslog-model, everybody can write logs, root can read) 2) Make vdelivermail setuid (vpopmail), and do setuid to the real virtualuser-uid after all db stuff. This would be clean, effective and dangerous. 3) Make a mysql-user for each system-user using vpopmail, nightmare - but maybe the cleanest way to do it. The mysql-information could be stored in the domain (system-user) homedirectory, almost as mysql do it default. Say something! > Can anyone think of other apps that have to deal with the issue of > storing MySQL login information securely? Sorry no. /Anders
