Re: [PHP-DB] Storing images in MySQL table
On Wed, Feb 19, 2003 at 11:07:28AM +0200, Corne' Cornelius wrote: The only disadvantage i've had of storing images in DB instead of Filesystem, is that when you use a PHP script to output the image to a client browser, MSIE doesn't always accept a suggested filename so it might try and save it as your-script.php?img=2. Perhaps using the syntax 'your-script.php/imagename?otherparams' would solve that. It does for the few cell phones I have worked on serving images to. At least apache allows that syntax. Other then that, keeping images in DB is a lot easier since you don't have to keep your DB in sync with Filesystems ie. Deleted records in DB, but images still exist. Certainly nice. Now if only postgres had a nice way to dump/backup BLOBs. :) Len Sorensen -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] crypt help
On Wed, Feb 12, 2003 at 03:33:22PM -0500, Zach Davis wrote: I have a question about the way I'm using the crypt function in a PHP/SQL gradebook I'm building. When I add a user to the users table, I also generate a encrypted version of their password using the following statement: // Crypt the password $crypt_num = crypt($student_num, $salt); // Crypt the password $crypt_pw = crypt($password, $salt); Then, when the user tries to log on later, they enter their password, and it gets encrypted in exactly the same way. The encrypted version of the PW is then compared to the encrypted version stored in a passwords table -- if they match, then the script validates the user and prints out the user's assignment scores. However, I've noticed that if anything past the 8th character in the password is irrelevant. So, if the password was 12345678910, and the user entered 12345678, the user would be able to enter. In other words, the encrypted version of 12345678910 would be the same as the encrypted version of 12345678. I think there must be something with my crypt statement -- any advice? If you want more than 8 characters, use MD5 or some such. Unix crypt as used for passwords doesn't do more than 8 characters. MD5 passwords can do much more. Len Sorensen -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Old memory contents appearing in files created by dba_open
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
Re: [PHP-DB] Old memory contents appearing in files created by dba_open
On Fri, Feb 07, 2003 at 05:38:04PM -0500, Len Sorensen wrote: 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. I also occoured to me, that any user that can create php scripts and run them, could use dba_open, to dump a chunk of memory to a file, and then send that file using readfile, or the like to the user viewing the page, even if that file isn't in a location apache itself would serve. What if that memory dump contained passwords used on other parts of the site? Does this concern anyone else? Len Sorensen -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
