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.
