But I thought since the user is going to access the db through the cgi script should be accessible to no-body. And the DB.pm module should be accessible too since it is referenced by the cgi. You at least need to have "4" (read only permission) for no-body in order to run the cgi.
David Kuo -----Original Message----- From: Hardy Merrill [mailto:hmerrill@;redhat.com] Sent: Tuesday, October 22, 2002 3:55 PM To: Kuo, David Cc: 'Hardy Merrill'; Juha-Mikko Ahonen; John Gedeon; [EMAIL PROTECTED] Subject: Re: Hiding the db password Kuo, David [[EMAIL PROTECTED]] wrote: > In this case, local users still have access to the DB.pm and it has the > user/password info, isn't it? No - previously in this thread I described setting permissions for DB.pm in a *nix environment to 750, where the owner is "john"(7 for read, write, and execute), the group is "just_us" (members of this group would be John, his boss, and the user that the webserver runs under - permissions 5 for read and execute), and 0 for "world", meaning no-one else can even see the DB.pm file. Hardy > > 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.
