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. -- Hardy Merrill Senior Software Engineer Red Hat, Inc.
