Lot 49: Greg Beaver's blog

Update: fixed character encoding of all blog entries, Planet PHP should pick this up shortly

All projects need a way to track problems that their users find, and also to define a strategic timeline that will decide when things get done and who will be doing them. Until recently, this involved using extremely complex non-PHP applications like bugzilla, wonderfully elegant but not free apps like wIT, or wonderfully complex applications with lots of extraneous third-party components like Horde's whups.

Setting one of these tools up can often involve a tremendous amount of configuration and require a good deal of knowledge about the internals of the project.

Being lazy, this bothers me, and so I took the code from pearweb's bug tracker at http://pear.php.net/bugs (found in CVS at cvs.php.net/pearweb/public_html/bugs) and modified it to work with my very own Chiara_PEAR_Server channel server. The code distinguishes itself from other bug tracking tools in that (assuming you have a running install of Chiara_PEAR_Server) setting it up involves just 6 steps:

$ pear channel-discover pearified.com
$ pear channel-discover savant.pearified.com
$ pear install pearified/Role_Web
$ pear run-scripts pearified/Role_Web
$ pear up chiara/Chiara_Bugs
$ pear run-scripts chiara/Chiara_Bugs

This is all that is needed to have a fully functioning bug tracker that:

1. automatically tracks both packages and releases as they are made in Chiara_PEAR_Server
2. understands developers directly from Chiara_PEAR_Server
3. separates HTML output from backend processing, allowing templating
4. has simple and elegant roadmap mechanism for defining release strategies, and assigning specific bugs to future releases
   

For example, the roadmap for Chiara_Bugs itself is defined and publicly accesible at http://pear.chiaraquartet.net/Chiara/Bugs/roadmap.php?package=Chiara_Bugs.? If you see a bug that interests you, feel free to drop me a line.? There is no future commitment, and one-time fixes are appreciated as much as steady developers.? The same is true of Chiara_PEAR_Server, roadmap at http://pear.chiaraquartet.net/Chiara/Bugs/roadmap.php?package=Chiara_PEAR_Server.

For those of you who already have accounts, if you want a bug, assign it to yourself, and take note of the scheduled release date, because I tend to hijack bugs that aren't resolved when we get close to the date .

This weekend, while I was away playing a concert, someone hacked into an insecure application on the same host that runs chiaraquartet.net and used it to initiate a denial of service attack.? As a result, the entire site was shut down and everything was moved to a new server.? Things are working again, but it took a while.? I had to re-install the stupid blog from scratch, so let me know if you find problems.

Due to Davey Shafik's prodding, I took a look at PHP_Archive again and found a few subtle bugs which are fixed in CVS. More on this later, the bug was caused by an interesting problem in the way fread() works inside a userspace stream handler.

But for now, I'm excited to have a unique demonstration of PHP_Archive's power. The file http://pear.chiaraquartet.net/phpmyadmin.phar (Note: right-click and save) is a single-file bundling of the popular phpMyAdmin application. The only thing it needs to function properly is a config.inc.php file. A template file is auto-generated on the first time it is run, so running:

$ php phpmyadmin.phar

will spit out the config.inc.php needed. All you need to do is modify the user/password and the kind of extension (mysql or mysqli) and it can be used. To use it from a website, either add .phar to the extensions parsed by PHP, or simply rename it to phpmyadmin.php. As always, PHP 5.1 or newer is required in order to run .phar files.

Somehow, I managed to erase the entirety of pear.chiaraquartet.net's database, although I have no idea how or when. In other words, all developers, release history, packages were wiped. Needless to say, I am a wee bit pissed off. Until I can find a decent backup, I will reconstruct the entire thing from scratch.

PEAR_RemoteInstaller is a package that makes it possible to synchronize installations of PEAR between a local computer and a remote computer, even if there is no shell access on the remote computer. To do this, it uses PHP's ftp, ftps and ssh2.sftp streams to copy files installed locally to the remote system. This new version therefore requires PHP 5.1 or newer to take advantage of the power of ftp streams, and no longer depends on the Net_FTP PEAR package.

This version is essentially a bugfix release, as the initial versions did not in fact work with PEAR version 1.4.3 or newer (I no longer had a remote host that supports unencrypted ftp access with which to test it). Although it adds ftps and sftp support, it does not change anything about the implementation of the underlying code, or the commands. Future versions will be far more user-friendly and well-thought out.

That being said, it does work (finally), and can be used for those users who would like to take advantage of PEAR packages on a host that provides PHP and ftp or secure ftp, but does not provide shell access.

UPDATE 2: Thanks to Chris Shiflett, who provided a link to a real answer in his comment. Clearly, the way to do this within the environment where you have one host and lots of ~users is to use .htaccess. Each user would define in their own /home/user/public_html/.htaccess two environment variables like so:

SetEnv DBUSER mysqluser
SetEnv DBPASS mysqlpass

PHP will get these variables passed in the $_SERVER superglobal as $_SERVER['DBUSER'] and $_SERVER['DBPASS'].

Even better, if the .htaccess is then chowned by an admin to the nobody user and then chmod 0600, it will be unviewable in the shell by anyone but root and apache. It would also be trivial to implement and provide a setuid tool such as "vicrontab" to modify .htaccess if necessary.See Chris Shiflett's last comment on this error

In this way, scripts would look like so:

This yields completely secure mysql user/pass per-user in a shared environment with 1 virtual host and lots of users who all have shell access.

Two days ago, I gave a talk at the University of Nebraska-Lincoln's computer science department colloquium on open source. At the reception preceding the talk, one of the students asked if there was a good way to protect the user/password of his MySQL scripts. This is an issue I have never run up against because we have a unique IP on the webhost, and it doesn't matter whether someone knows the user/pass, they can only connect directly from that host (and if someone can hack into the host, I doubt the database is the only thing that will be compromised).

Our student, however, had been browsing student accounts and noticed that one student had a particularly attractive webpage that couldn't have been coded by the student. It turned out to be an install of wordpress, so he thought he might give it a try. While installing the program, he noticed that the MySQL username/password was stored in plaintext in a wp-config.php file (or something of that nature), and so thought "hmm, I wonder if other UNL students can see the password." To test, he tried "cat /home/user/public_html/wordpress/wp-config.php" and sure enough: there it was in plain sight. This would not be an issue were it not for the fact that every student runs on the same site, and so all have access to the same mysql space, all they need is the password.

Having never run into this issue before, I came up with a PHP-based solution, and a MySQL-based solution, but neither makes me tremendously happy, so I wonder if any of you have a working solution to this problem in place

What I came up with was:

1. each user's web space has its own virtual host that is used to grant mysql privileges, so instead of "http://www.example.com/~user" we would have "http://user.students.example.com". In this way, it is not possible to connect to the mysql server unless you are accessing it directly from the web host. This, however, is likely to prevent the usage of the command-line mysql program, as it will attempt to connect from localhost.
2. The password is saved in a read-only file that is created by the web server itself.

The second method works in tandem with an open_basedir restriction in php.ini to the user's home directory. Basically, how it works is this simple system:

1. First assume our user is named "joeshmoe" and the user has shell access to /home/joeshmoe, and web root is /home/joeshmoe/public_html, the mysql password is 'mysqlpassword', and we are using PHP 5
2. login as joeshmoe to the unix shell
3. mkdir /home/joeshmoe/passwords
4. chmod 0777 /home/joeshmoe/passwords
5. save this script as /home/joeshmoe/public_html/savepassword.php:
   
   < php
   file_put_contents('/home/joeshmoe/passwords/mypass.php','mysqlpassword');
   chmod(0600, '/home/joeshmoe/passwords/mypass.php');
    >
6. browse to "http://www.example.com/~joeshmoe/savepassword.php"
7. chmod 0000 /home/joeshmoe/passwords
8. rm /home/joeshmoe/public_html/savepassword.php

At this point, to use the password, all you need to put in your scripts is "file_get_contents('/home/joeshmoe/passwords/mypass.php')" instead of "'mysqlpassword'", and only the webserver will be able to read the file. open_basedir will make it impossible for any external scripts to read the password.

Any comments