I was playing around with figuring out why dba_open creates an ndbm database when run in stand alone mode (as requested) but creates a db2 database when run as an apache module. This is in php 4.2.3 on a Debian 3.0 system. I haven't tried with 4.3 yet. I am not sure if this is a bug somewhere, or a configuration problem, but it does seem odd. Something I noticed while playing with this, is that all the files created by dba_open contain a lot of other old memory contents from the apache/php process when created, some of which perhaps shouldn't be dumped into files being saved. My guess is that when the db lib used by dba_open creates a file, it does a malloc of a certain size, and uses that as the basis for the file, and it doesn't clear this memory (after all why should it care what is in it before it creates it's db structure). I assume that when php's garbage collector frees memory, it does not clear it, and hence script code, sql query contents, etc are still present in the freed memory, which may be allocated by another malloc later in the same thread without being cleared (since it was already used by that process there is no point in the OS clearing it, assuming the OS is ever responsible for clearing memory). As a result, content of SQL queries sent to postgres from a previous request on that web server, may end up written to the db2 or ndbm or gdbm file (whichever is used), when you create a new file with dba_open, meaning potentially private information could end up in a file you may end up giving to someone else later. So does anyone have any idea who is to blame for this problem? Is it PHP? libc? The OS? Apache? The DB library in use? I am certainly not sure, but given I don't know of a way for the php user to make php wipe it's memory, I can't think of any way to prevent the data from ending up in the file, short of changing the lib*db* code to zero the memory it allocs before writing the file. Somehow that seems like the wrong place to attack it. Calling bzero every time you call free in php also seems like the wrong approach. Opinions and possible fixes are welcome. Telling me another mailing list that is better suited for the question would be fine too given this could happen with other libraries included with php. Len Sorensen -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
