Permissions for Common File Types

In a previous post, I explained how to use chmod to change file permissions and also provided some security tips to ensure your file permissions are not more permissive than they need to be. Looking back on those posts, I think it would be useful to list some common file types and the maximum permissions that those files should have. The maximum means that there is no legitimate reason for those files to be any more permissive.

(r = read, w = write, x = execute) (Owner, Group, Other)

1. Executables – CGI files – Perl scripts, for example, often need to be executable. 755 (rwx r-x r-x)
2. Regular HTML and PHP files – These only need to be read by the outside world. 644 (rw- r– r–)
3. Private files – Sometimes text data files are stored on the server but do not need to be seen. 600 (rw- — —)
4. World writable – use these only if absolutely required by the application. 666 (rw- rw- rw-)
5. Full permissions – almost never necessary and could cause security problems. 777 (rwx rwx rwx)

There are other combinations, but these are the common permissions for files on most Linux servers. Only change file permissions if necessary. Otherwise, keep them as conservative as possible. This will ensure the security of your website(s) and server.

PHP module vs PHP CGI binary

Question: What are the differences between running PHP as an Apache module and running it as a CGI binary on a Linux server?

Answer: One of the biggest differences between a PHP Apache module and a PHP CGI binary is that the Apache module is just that: a module of Apache that is dependent on the web server. They are intrinsically linked. If one goes down, so does the other. A PHP CGI binary is separate program entirely that runs under a different user than the web server. If something goes wrong with PHP, Apache is generally unaffected.

The primary benefit of PHP as a module is speed. When the web server loads, all of the PHP settings and configurations are loaded with it. They stay resident in the memory as long as Apache is resident and running. The drawback is the decreased security of having PHP code run by the Apache user and the fact that any changes to configuration files require an Apache restart. The advantage of PHP as CGI is the stability and security of an independent user running PHP. One of the drawbacks is that it has execute PHP for each instance of a script, which can take a heavier toll on the CPU and create a larger number of processes.

Both methods have benefits and drawbacks, and it is up to the server administrator to decide which is the best for a given situation. Once a policy is set, it is not a good idea to change it, because such a major reconfiguration could adversely affect running scripts and applications. Decide what the best course is for you and stick to it.

Make your own forum website

There are many issues to consider when creating your own forum website: themes, topics, moderators, administrators, categories, advertising, user permissions, and policies. One of the most important decisions you will make, however, is choosing the forum software. Discussion forum software can be proprietary/commercial or free and open source. It can be CGI-based, PHP-based, or any other number of scripting languages. It can use a database backend or a flat file backend.

In 2008, forum-software.com rated MyBB as the best open source forum software, awarding it 4 out of 5 stars. They ranked vBulletin as the best commercial forum software, giving it 5 out of 5 stars. Interestingly the site’s users gave MyBB a higher rating (4/5) than vBulletin (3/5).

Find out what forum software is out there, what software features your server supports, and how much time and money they will cost you. Most importantly, make sure the one you choose is one you will want to stay with for a long time. Nothing is worse than trying to migrate users and forum posts from one application to another. Take your time and make the decision that works best for you and your users.

How to troubleshoot an Internal Server Error

Question: My CGI script is giving me a 500 Internal Server Error. What should I do?

Answer: It is one of the most dreaded errors Apache can throw at you: the 500 Internal Server Error. When you get it, you often have no idea what caused it or why. Here are a few things you can do to troubleshoot it.

1. Check the location. Make sure you have uploaded the scripts in the right place.

2. Check the upload method. Your FTP program should upload Perl scrips in ASCII not in binary mode.

3. Make sure the file permissions are set to 755 to make the script executable.

4. Often times modifications to the script, if required to configure, can cause an error. You might have slipped in an unsupported character or made a typo.

If it still does not work, try running the script from the command line and see if it spits out an error. If you still cannot figure it out, you might want to talk to the developer. The script just might be incompatible with your server. Most importantly, don’t give up.

Photo: Flickr

What is a cgi-bin directory?

Question: What is the purpose of a cgi-bin directory?

Answer: CGI programs running on a server must be executable. While this allows the user to run server-side scripts, including convenient free ones found on the web, it also presents a security risk. Most virtual hosting situations restrict execution of Perl scripts (and possibly other types) to one directory, usually called cgi-bin.

By doing this, scripts can be regulated from having access to the rest of the server, and users will not have to worry about setting the same type of restrictions on other directories. Attackers will always be limited in the amount of damage they could do with invasive scripts.

Apache HTTP Server does not enable CGI by default. If your web hosting provider has not enabled CGI, ask them to see if it can be enabled. For information about enabling it on your own server, see this site.

Photo Source: Flickr

Finding good free scripts for your website

A good web hosting company often provides its website owners with automatically installable scripts for various popular tasks: blogging, photo albums and e-commerce, to name a few. In some special situations, however, it becomes necessary for a webmaster to search for free, reliable scripts on the web. Whether they are Perl, PHP, or ASP scripts, there are some good places to look.

Hotscripts. Hot Scripts is one of the older more well-known script repositories. It provides links, ratings, categories and annotations of thousands of Javascript, C, PHP, Flash, ASP, CGI, Python, and other scripts. This site lists both free and commercial scripts.

PHP Resource index. Another well-known and trusted site, PHP Resource Index lists both free and commercial scripts, allowing users to vote and comment on them. It currently has around 4,000 scripts indexed. Its sister site, CGI Resource Index, lists Perl and CGI scripts.

There are many other script indexes and repositories. Whichever ones you choose, it is important to be mindful of security, not just of your own website but of the entire web server. You will be responsible for installing any updates to your scripts and making sure they are secure. It is also important to understand that you, not your web host, must make the scripts work since you acquired them from third parties.

Photo: Flickr