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

Reply via email to