On Thu, November 30, 2006 9:59 am, Edwin Barrios wrote:
> I don't know if my solution is better or not. but in one of my
> programs i
> had to make a backup online then my solution was to use shell vars to
> put
> important information like db_password . When we use putenv function
> those
> var only exists on the current shell and on its subshells. In your
> case the
> following code :
>
> <?php
> putenv("DBNAME=".DB_NAME);
> putenv("DBUSER=".DB_USER);
> putenv("DBPASSWD=".DB_PASSWD);
>
> system('mysql -h localhost --user=$DBUSER --password=$DBPASSWD -D
> $DBNAME
> < "/my/import/script.sql" 2>&1');
>
> ?>
This solution, as most good ones, has pros and cons:
Pro:
Does keep the password from being exposed in the normal course of
operations.
Con:
A simple debug statement to dump out all of ENV / $_GLOBALS will
expose the password.
So you have to ask yourself if you and all your employees and all the
scripts you ever install, including any forums etc, are for sure never
ever going to dump that password out in an attempt to debug something
else.
For a solo developer or even a small team, with all custom hand-coded
stuff, this is pretty easy. But once your application blows up and
you have a larger team, or you start caving in to client demands to
install badly-written forums/carts/blogware, you are open to a
potential security hole which:
has two seemingly unrelated contributing causes
the two causes can be years apart in time
both are simple straight-forward "obvious" Right Things to do
So you have to weigh carefully the Risks, and DOCUMENT what you did
and DOCUMENT what *not* to do in the future to expose this sensitive
data.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
