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

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

Say something!

> Can anyone think of other apps that have to deal with the issue of 
> storing MySQL login information securely?

Sorry no.


Reply via email to