Re: hiding passwd in cmdlines that appear in the process list

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.