tg-php@xxxxxxxxxxxxxxxxxxxxxx wrote:
> If you did use ENV to set the username and password, you could always unset it using the same method after you ran the mysql command. So it'd only be exposed for a very brief period of time and slightly less accessible than just running a process list.
>
indeed I do the following directly after the relevant call to exec() :
putenv('MYSQL_PLESK_PWD=doreallythinkIwouldleavethispwdfloatingaroundinashellenv?');
> It still falls under the category of "security through obscurity" which isn't a best practice scenario. But I can't think of another way to run mysql under these circumstances that's any better.
but given that the ENV var is only available to the shell php in currently running in (and any subshells) so
the script is only vulnerable to mistakes/attacks from 'inside' the script - basically I'm assuming that
whatever is stored in the ENV of a shell is not accessible/visible to other users on the given system.
is that assumption correct?
>
> -TG
>
> = = = Original message = = =
>
> On Thu, November 30, 2006 12:29 pm, Edwin Barrios wrote:
>> This is not triue because a shell vars declered on a shell is only
>> exposed
>> to its subshells, that means that only exec's and system functions
>> calls
>> into the php itself resive those vars declared into the php !
>>
>> You can see this argument in the following code
>>
>> <?php
>> error_reporting(E_ALL);
>>
>>
>> echo "OLD <pre>";
>> system("env");
>> echo "</pre>";
>>
>> putenv("DBNAME=sidf");
>> putenv("DBUSER=p");
>> putenv("DBPASSWD=p");
>>
>> echo "NEW <pre>";
>> system("env");
>> echo "</pre>";
>>
>> ?>
>>
>> and reloading these a couple of times.
>
> My point was that somebody who was doing:
> system("env");
> in a different part of the script, to debug something else, will
> expose the password, probably without even realizing it.
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
