PHP

parsepath.pl is a brilliant perl script for fixing permissions problems on Unix based platforms by Jeremy Mates. Probably the most common type of permission problem from a sysadmin/webmaster's viewpoint is uploading a file to a directory in a website's document root folder and then trying to access the file or script in a web browser only to get the dreaded 403 error message:

Forbidden
You don't have permission to access /foo/bar/test.php on this server.

Most time the solution is very simple, just change the permissions on 'test.php' to make sure the user the webserver runs as can read the file correctly - the simplest and most common method being to change the mode of the file to '755':



Unfortunately sometimes it's not that easy and many times you see users asking 'I'm getting 'access denied' errors even though I've changed the perms to 755'. The problem is that one of the subdirectories that the 'test.php' file lives in has permissions set so that the webserver can't read the file properly. Now that's where the headache comes in :)

However, parsepath.pl can take the headache out of fixing permissions problems.

Say you have a website document root directory tree /usr/local/www/web/www.munk.me.uk/foo/bar and you upload a web script 'test.php' into that directory. You try and access the file in a webbrowser but get the 403 permission denied error above. First off you check the permissions on the file itself:



That looks ok, with permissions 755 and the owner/group set to 'www' the webserver user 'www' should be able to read the file ok. So in this case the problem must be with the permissions on one of the parent subdirectories. The old method of working out the perms would be either to trawl one by one through each directory checking the perms on each subdirectory or to change the permissions recursively on the document root folder so all subfolders have the read bit set for the webserver user/group.

With parsepath.pl things are a lot simpler though - just run the following command:



With this command parsepath.pl recurses through each subdirectory below the file/path you feed it on the commandline and tells you the permissions problems - if any - for the user 'www' (the user=www argument) to read (the +r argument) the file 'test.php'.

In the output, we're told that permissions to read the test.php by the user www fails on two counts:



With this information it's easy enough to go in and make the changes necessary to fix the problem using 'chmod g+rx foo foo/bar'.

There are other ways of invoking parsepath.pl though. Running it just with a file/path as an argument it'll tell you the permissions on each subdirectory under it:



which can is better to see a whole tree in one go.

No permissions were harmed in the making of this article!


I'll include the parsepath.pl script in the extended article just in case the original ever gets lost - big credit of course goes to the author of the script, Jeremy Mates. His site is actually very interesting from a sysadmin's point of view containing lots of interesting admin scripts and thoughts on system administration in general - spent quite a while grazing through his stuff there - cheers Jeremy.

Quite a while ago I posted a question to the freebsd-isp mailing list about a minor modification that could be added to the apachectl apache startup shell script to stop it from displaying a lot of sensitive information when PHP and other CGI applications display apache's environment information to users. A bit mouthful - the gist of it is that when you use apachectl to start/stop apache from a shell, the environment variables of the shell user that invokes the apachectl script become available to CGI applications by default.

For example in my case the following types of sensitive environmental information is available by default when someone runs phpinfo.php on my server:



and so on along with all the other environment variables I have set in my default root shell - not really what I want displayed to all and sundry :P To see this yourself on your own server, try running phpinfo() from a php script:



Anyway the solution I found is to 'sanitize' the environment when the apachectl script starts up the apache httpd process by using the following simple line in apachectl:



A problem report I was considering sending to the FreeBSD ports team is included in the extended article below - I didn't bother sending it in the end because it's not really a FreeBSD issue. Not sure why I didn't send it to the Apache mailing list though, I thought I did but I can't find it now. Ho hum.

This is by no means a new attempt to exploit a vulnerability in a PHP web application, but since I started using snort as a full time intrusion detection system I've picked up countless attempts to exploit a vulnerability in an online PHP photo gallery called My_ eGallery. The annoying thing about this is that I've never had this gallery system installed on any of the sites I maintain - particularly the one that keeps getting hit - but they continue to try their exploits. Read on for more...

Been very quiet this week - over 10 days since last posting... hrm where's the time gone?

Anyway just yesterday I added some 'remember me' functionality to the SimpleAuth code base, detailing the changes needed in the SimpleAuth FAQ. The FAQ seems to have gone down a treat - since writing it a few months ago the number of questions has gone from 2-3/week to about 1/fortnight - score.

Anyway the details about the code are in the FAQ here:

SimpleAuth Remember Me