Re: [maildb-devel] Re: DB authentication

[Darrell K. <dk...@ya...>]

li...@av... wrote:

>
>> My question is: how do we authenticate to the database?
>> ...
>> Do we just put a 0400 file somewhere on the local filesystem that only
>> root and the mail.local user (probably "mail" or "daemon" or ...?) can
>> read that contains th DB username and password?  The only other way 
>> that I
>> can think of would be to compile the DB username/pw in the mail.local
>> executable, but that might make it vulnerable to "strings 
>> mail.local", or
>> something along those lines.  Is there a standard way to do this kind of
>> thing?  We're not trying to protect from root in this case -- we're only
>> trying to protect from other users (right?) -- so I'm thinking that a 
>> 0400
>> file might not be totally evil (one way to think of it: it's no less
>> secure than 0600 /var/spool/mail/* mbox files).
>
>
> That's one way to do it.  Another way that we used at A Former Company 
> of Mine (Collective Technologies, Austin TX) was to do a simple 
> encryption of the database username/password into a "keyring", and our 
> perl subroutine that handled the database connection extracted/used 
> that information.  It was more obfuscated than it was secure ... but 
> we figured every little bit helped.  :-)
> - Liza
>
> -----

I really like that idea -- and there's no reason that the encryption 
would need to be simple -- it could be PKI -- when you start the daemon, 
you specify a passphrase to get your private key which can decrypt the 
passwords on the publicly encrypted ring.

But...

Unlike filtering, is this really a maildb issue?

Presumably, you're not going to be writing implementations for each and 
every potential database that someone might use.  Additionally, 
different DB vendors will use different authentication strategies. 
 Assuming that the DB shim is developed externally (using Yet Another 
Well Defined Interface (soap, odbc, sql), it seems that for the purposes 
of release you'd want to keep the underlying mechanism as simple as 
possible; both functional and tutorial.  To that end, I would think that 
even an environment variable in a root owned start script would be 
sufficient.  Sure it's ugly, but it's easy to understand.

-D