Pardon my jumping in here, but I believe the answer to your question is Yes.
On another track, is OS authentication an option for the DB you are using? No password is required if OS authentication is used. The OS does the authentication and the DB just asks the OS. Works pretty well for SQL Server. I've not had much use for it in Oracle, but I know it exists. I'm not sure if its supported in DBI, though. Of course, that doesn't solve your problem if another user can 'su' to your special OS user with DB privileges, if you're really trying to secure the DB. If security is that important, maybe you should consider another box where you can secure everything. If a password is required by an automatic program, then the password has to be available to the automatic program. By definition, root (or Administrator) can always see that file (you do want it backed up, don't you?). By convention, that password is required to be presented as plaintext. Just my $0.02. Dave On Oct 22, Kuo, David scribed: > In this case, local users still have access to the DB.pm and it has the > user/password info, isn't it? > > David Kuo > > -----Original Message----- > From: Hardy Merrill [mailto:hmerrill@;redhat.com] > Sent: Tuesday, October 22, 2002 3:35 PM > To: Juha-Mikko Ahonen > Cc: Hardy Merrill; John Gedeon; [EMAIL PROTECTED] > Subject: Re: Hiding the db password > > > Juha-Mikko Ahonen [[EMAIL PROTECTED]] wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Tuesday 22 October 2002 21:41, Hardy Merrill wrote: > > > Assuming you create a Perl module outside of the webserver's > > > document root, the tricky thing is that for cgi scripts, the > > > user that the web server is running as needs at least "read" > > > access to that file that contains the DB passwords. > > > > This solution works as long as all of the programmers are "trusted" > > users and only non-programmers are "untrusted." Creating a script which > > prints out the DB password would be quite easy. But if the programmers > > are not a concern, then there is no problem with the filesystem rights > > management. > > Better still would be to, instead of just placing the passwords > in a separate module, to place the entire "connect" into its own > subroutine in that separate module. That way, the only access > to that password info would be through the also encapsulated > connect subroutine - so the only exposed call is to the connect > subroutine: > > /var/my_perl_modules > -------------------- > DB.pm - contains subroutine "my_connect", which either > returns a good $dbh, or undef(if unsuccessful) > > /var/www/cgi-bin/my_script.cgi > ------------------------------ > use lib '/var/my_perl_modules'; > use DB; > my $dbh = DB::my_connect(); > if (!$dbh) { > ...bad error...do something drastic#### > } > > No password info is exposed to scripts that use the connect. Can > you see a way in this scenario that a non-root programmer could > easily print the password info? > > > Another solution (as Henri Asseily pointed out) would be asking the > > password each time the Apache configuration changes, someone unplugs > > the power, frustrated cracker forkbombs the system... Not a bad > > solution on a stable environment, though. SSL uses the same method. > > > > The simplest method of all would be to eliminate unauthorized access > > using the database management systems authorization schemas. For > > example, you could allow access to the database for only selected Unix > > users. This is done using the access control methods offered by the > > DBMS. > > > > If no-one can su(1) to www-data (or some other user Apache runs as), > > only root, www-data and other selected users can connect to the > > database. No passwords needed. > > I've done this before with the Postgres DB - using Postgres "ident" > authentication, a user only gets access to a database if that > user is both a system user(has a regular system user account), > and a postgres user, and that user successfully logs in to his > regular system account - then he is granted access(this is a very > simplistic view). Couple that with "suexec" and you have pretty > good privacy(no pun intended) for your passwords. > >
