PHP Contributions / More secure PHP db passwords

From: Date: Fri, 15 Sep 2000 00:01:19 +0000
Subject: PHP Contributions / More secure PHP db passwords
Groups: php.dev 
Request: Send a blank email to php-dev+get-32982@lists.php.net to get a copy of this message
Hello, I've just written a couple of functions for php4, and I think they may be useful to others, and I'm wondering how to contribute them. Here's the problem I set out to solve... In many cases, users can steal passwords from other php users. In virtual hosting environments, it's nice to be able to offer php in addition to more customary CGI server side programming support. It isn't always practical (or as secure as you might think) to run seperate httpd deamons in chrooted environments for each user, so often users are sharing the same view of the file system(s). Each virtual host generally has a seperate user ID so that users can't overwrite each other's files. Apache can run CGI's under suexec which allows them to run as the owner of the CGI instead of the user ID apache is running under. This is great because it allows CGI's to only be readable by the user that owns the CGI, and to run with that user's permissions. This lets users protect the passwords (typically for database access) with permissions that only allow the user to read the source file. Enter php... Scripts are still owned by the user that owns the virtual host. However, since most apache setups use the apache module version of php, the script must be readable by the web server, which generally means global read permissions. If we were exclusively php based this wouldn't be a problem because we could just use safe mode, but in a mixed php and cgi environment, it means that users could write cgi's to steal passwords from php files. I've solved the problem by configuring php to treat .pcgi files as php cgi, and run the interpreter under suexec. This solution works, but it is ugly and not efficient. Enter my pvt extension... Today I wrote an extension which I've called pvt for private. It allows php scripts to set and get token values, which are stored in files that are only readable by the uid/gid of the web server, and nobody else. The idea is that if all cgi's run under suexec, and if safe mode works, then nobody will be able to read the contents of the token files, except those who should be able to read them. Don't get me wrong - I don't consider storing plain text passwords secure, but since they have to be stored plain text (or obscured plain text such as xor'd, which doesn't really buy us anything) in order to be used with database and other servers anyway, I think this is better than where we were. At least now an attacker would have to compromise either the uid of the web server or the root account to gain access to the passwords of the users. As it was, any user with an account on the system who knew the concepts behind suexec and php could get the passwords. Now my question. How can I either contribute this extension to the main php4 distribution, or make it available as an add-on? I used the ext-skel script to get started, and I really appreciate the efforts of the people who created that script. It was easy to get started. Now, how do I distribute the update? I can share the contents of the folder created for my by ext-skel, but it wouldn't have the updates to the configure script, etc. I could distribute a patch for php, but that seems kind of ugly since I'm really just adding something new. I know there is the ld php call for loading an extension on the fly, but when I build my extension I don't get a .so file. It seems to me that this is preferable to distributing just a patch, since many users probably just use rpm to install php. I'm sure documentation exists somewhere that explains how to either contribute an extension or provide one for easy use for binary distribution users. If someone would be so kind as to point me to that documentation, I would really appreciate it. I'd also be eager to hear from you if you have a better way to solve my problem. Thanks in advance, Vic.

« previous php.dev (#32982) next »