Solved

Proper Permission for Apache and PHP applications

Posted on 2008-06-18
7
288 Views
Last Modified: 2012-05-05
Hi,

Im in charge of two RHEL 5.x servers with Apache 2.x and PHP 5.1.x
A team of programmers just installed an application to the server and they want to chmod 777 almost all the files and directories their application uses, claiming that without this, the PHP code will not run properly.

Most of the application is written in PHP with calls to external utilities like html2ps.

There is a temporary directory where users should upload documents and another temporary directory where html pages are transformed into PDF using html2ps php module.

My questions are (not being  a security expert)

1- Is it wrong to chmod .php and .sh scripts with 777 under the webroot directory of Apache?
I guess there is no need to chmod 777 a script, but since I am not a php programmer.....
2- Can I chmod 775 and chown root:root all files under webroot?
3- Is it ok to chmod 777 the two directories for uploads and html2ps conversion only?
4- Why would a php programmer say that he needs 777 to make a .php work?


thanks,
0
Comment
Question by:erickperez
  • 4
  • 3
7 Comments
 
LVL 24

Expert Comment

by:glcummins
ID: 21815788
If a developer is asking for such permissions, he is doing something wrong. It is a gaping security whole to do what is being asked in this case.

Now, if this server is an internal server with no ties at all to the outside world, you are probably safe making these changes. Your only risk is from internal maliciousness, and you can choose to deal with that how you wish.

However, if these will be external servers which can be accessed by the world, you are opening yourself up to very dangerous exploits.

First, changing file permissions to 777 allows any user on the system to modify those files. This can be a user that is logged in directly, or a user that is accessing your server via a script, and exploiting that script to do his wishes. As long as you keep such permissions to a minimum (like on temporary or user-upload directories), you should be safe. However, you should never change a script to 777, because if that file is modified by a malicious user and then executed, you are at the mercy of the code that has been placed in the script.

Second, on a public-facing webserver, neither Apache nor any PHP script should *EVER* be run as root. *EVER*. The reason is the same as above: giving a script root access is equivalent to running 'chmod -R 777 *'. You are making every file and directory on the server writable to that script. If that script has security holes which allow an attacker to exploit it, you are in for some serious trouble.

A common reason that a developer wants a script to run as root is because he wants output from a system command, and will be using a function like exec() to run it. This is fine, again, in a closed environment, but never on a public-facing server. The potential for abuse is just too high. Instead, any processing that is needed should be done either via PHP-only method, or should be queued on the server to be processed independently as a batch by the appropriate command. For example, if the script needs output from the html2ps command, you should do the following:

 1. Write the script so that it saves the HTML file into an appropriate directory.
 2. Allow the script to set a flag, either in a database or a flat file, to notify a daemon that a file is waiting to be processed.
 3. The daemon sees that a file is waiting, and calls html2ps to process the file, writing the output to a webserver-accessible directory.
 4. The script checks for the existence of the processed file, and acts accordingly.
0
 
LVL 24

Expert Comment

by:glcummins
ID: 21815804
Spellchecker is on vacation. "security whole" should be "security hole"
0
 

Author Comment

by:erickperez
ID: 21816044
Hi glcummins,
This will be an internet facing server.
Since we are running Redaht EL with apache and php as RPM packages....
Web server is as usual running as user apache group apache.
I am thinking of chmod 775 all files below /var/www/html/* -R
Also, chown root:root: /var/www/html/* -R

Security speaking, is it ok?
0
Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 
LVL 24

Expert Comment

by:glcummins
ID: 21816106
775 still gives any rogue script on the server the ability to change any of your scripts. I wouldn't ever do that on my server, especially if there is a way for other people to upload scripts to the server to be run as root. Consider this scenario:

 I have a script that checks user logins for my site. It accesses the user database, checks a username and password, and logs in a user if the info is correct.

 Now suppose that another script exists on your server which has been placed there by a malicious user. Normally, he would be able to write to only his own files. However, since his script will run under Apache, and since you have given write access on all of your files to your scripts, his script can now modify *your* scripts. He can add a little line in your code that will log all usernames and passwords to a file he can access, for example, or scrape user credit card information, etc.

Next, regarding changing the ownership of the scripts to root, I urge you in the strongest possible terms to reconsider. As I stated before, this will give your scripts complete control over the entire server. If there is any input validation problem in any one of the scripts, that script can be used to completely decimate your server. I would strongly recommend that you find another way to get the data that you desire rather than running your scripts as root.
0
 

Author Comment

by:erickperez
ID: 21825065
So in that case,
What user/group do you recommend chown the .html .php and .js files that exists on the webroot?
what perms for the files?
r-- for html?
r-x for js?
r-- for .php?

thanks,
0
 
LVL 24

Accepted Solution

by:
glcummins earned 500 total points
ID: 21825103
I recommend that the files in the webroot be owned by the apache user and group. Check the httpd.conf file for the user and group that Apache runs under, and make your files to use the same user and group.

There should be no difference on file permissions for HTML, Javascript, or PHP files. They are all read directly by Apache, and need no special permissions as long as Apache can read them.
0
 

Author Closing Comment

by:erickperez
ID: 31468514
Thanks for your assistance. I feel more confident now with this and future installations.
0

Featured Post

Complete Microsoft Windows PC® & Mac Backup

Backup and recovery solutions to protect all your PCs & Mac– on-premises or in remote locations. Acronis backs up entire PC or Mac with patented reliable disk imaging technology and you will be able to restore workstations to a new, dissimilar hardware in minutes.

Join & Write a Comment

Part of the Global Positioning System A geocode (https://developers.google.com/maps/documentation/geocoding/) is the major subset of a GPS coordinate (http://en.wikipedia.org/wiki/Global_Positioning_System), the other parts being the altitude and t…
If your site has a few sections that need to be secure when data is transmitted between the server and local computer, such as a /order/ section for ordering or /customer/ which contains customer data, etc it would of course be recommended to secure…
Learn how to find files with the shell using the find and locate commands. Use locate to find a needle in a haystack.: With locate, check if the file still exists.: Use find to get the actual location of the file.:
The viewer will learn how to create a basic form using some HTML5 and PHP for later processing. Set up your basic HTML file. Open your form tag and set the method and action attributes.: (CODE) Set up your first few inputs one for the name and …

706 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now