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
