|
From: Jeff S. <jsq...@os...> - 2003-07-09 20:24:57
|
On Wed, 9 Jul 2003, Darrell Kresge wrote:
> > 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. :-)
>
> [snipped]
> 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.
I think the central issue is that the mail server process has to be able
to access a secret somehow. If you need one secret to get to another,
then that really doesn't solve the problem -- that the maild server
process (or proxy that continually gets launched via mail.local or
whatever) needs to be able to connect in an automated fashion.
And since we're not trying to protect from root -- we're only trying to
protect from other users -- a 0400 file seems like a nice, simple solution
(and easy to debug/maintain).
--
{+} Jeff Squyres
{+} jsq...@os...
{+} Research Associate, Open Systems Lab, Indiana University
{+} http://www.osl.iu.edu/
|