Jochem Maas wrote:
tg-php@xxxxxxxxxxxxxxxxxxxxxx wrote:
You'd assume those ENV variables are secure.. or secure "enough". I know there's no such thing as perfect security, but I still wonder if there's a better way.
Although at this point, if there was a way to read other process/subprocess ENV variables, it'd most likely be something an attacker would have to get at by being fairly close to the system (trojan installed as root and exploiting an OS bug that allowed access to ENV variables from other processes for example). So I'm guessing this is about as secure as you're going to get for now.
thanks - nice to have a few extra brains executing this 'thought experiment'
The problem still bugs me though.. hah.
yeah it niggles a bit. I keep hunting about now and again to see if I can learn how
seasoned shell scripters tackle such security issues - undoubtedly I'm not the first to come
accross these issues, I am after a very small hobbit standing on the shoulders of very tall ents.
Modifying your $ENV will only affect that session in bash (I'm sure the
other shells work the same).
Try modifying your $PATH in one session, start another and you will get
the original $PATH in the new session..
I guess the underlying apps (mysql, postgres) do something to hide the
password in the process list. How? No idea ;)
Actually thinking about it you can have a .my.cnf stored somewhere and
point to that..
[client]
user = XXX
password = XXXXX
mysql --defaults-file=~/.my.cnf
but then it shows the path to your .my.cnf file instead, which is
equally as bad..
maybe you can use this as an idea:
Default options are read from the following files in the given order:
/etc/my.cnf /var/lib/mysql/my.cnf ~/.my.cnf
--
Postgresql & php tutorials
http://www.designmagick.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
