Richard Lynch wrote:
> 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.
the script can only be run by root with the php cli, and all the relevant
files are only readable by root.
so I think it would be fairly safe.
>
> 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.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
