By stabbis on

Hi there,

Thanks in advance to anyone that can explain this to me. But I cant seem to find the answer anywhere.

Simply: What is a 'Production Server'?

Im hosting sites with IX Web hosting, and Im using drupal. Ive been told that I should never set directories to 'CHMOD 777' wide open in 'productions servers'.

What are Production Servers and what are the alternatives..???

??????
Cheers
James

Comments

rtandon’s picture

rtandon commented

Hi James,

In the web server business / technology, like any other technical environment there are two very distinct phases: The period during which a developer / scientist / technologists work on a concept or model or laboratory prototype and second phase is the one when the technology, science or methodology is actually used in real life. For example, an automobile designer may work for several months, creating, modifying, rejecting a particular design several times before arriving at the final automobile design which is eventually used in production and commercial marketing. A medicine may undergo several different formulations and trials and tests before it is actually sent to the hospitals / market.

These two separate phases are known as development environment and production environment.

In the web technology, very often the developers use separate servers (or in some budget constrained environments, two separate domains or subdomains). One where they do testing work. The modifications to code, graphics and layout etc is done, modified and then re-done. Finally it is put on to the server and goes live. The former server (or sub domain, or folder) is called test / development server and the later is called "production server" or "production environment"

Sometime, the server is just one - the test and production is differentiated just on a time scale. Initially, the server is restricted to some I.P. addresses only and not visible to public while developers do their work. Once they are done, the server is open to the desired audience and desired security implemented. In this case, the same server is used initially as development server / development environment and later the same server becomes a production server (aka production environment)

I hope I have made it much more elaborate than it is neeed. Just with a view that it might be useful to some - to understand the concept and other variant terms referring to conceptually the similar things.

cog.rusty’s picture

cog.rusty commented

So, what you have been told is that you should never chmod directories to 777 on a live site.

A commendable goal. Most sites in the world on shared hosting plans would be happy if this was possible. Not that they are doing bad now.

shinsui’s picture

shinsui commented

777 on a production server is bad. A production server should be as safe as possible and having directories world writable is not safe. The most you want is 775. Writable for the owner and in some cases the webserver. No more.

cog.rusty’s picture

cog.rusty commented

The practical problem is that

- with a CMS you *always* want some directories writable by user apache, and
- on most shared hosts user apache falls under the *third 7* in 777 ("every user account on the server")

So, most people have to use 777 which allows write access for all users accounts on their server, except if some additional measures have been taken.

Usually the second 7 ("members of your user group") is just not used. If it was used for apache, then other users accounts on your server would be able to write to your 775 directories using an apache script (again, except if some additional measures have been taken).

---------

And of course, the first 7 is "you", which won't work for apache on most servers. Although some hosts such as site5 do some nifty script ownership trick which allows apache to write even with 755. But those are rare.

stabbis’s picture

stabbis commented

The description for production server was especially helpful, clears things up a lot. Thanks for the rest of the input too.

Just an update, I have contacted my hosting service and they say they can CHOWN files for me at my request. Does this change the level of security for file permissions?

If I were to CHOWN 777 as opposed to CHMOD 777 a file, will that improve the level of security?

Thanks again in advance
Cheers
James

cog.rusty’s picture

cog.rusty commented

There is no "CHOWN 777". CHOWN is "change owner".

http://www.oreillynet.com/linux/cmd/cmd.csp?path=c/chown

CHOWN new-owner filename changes the ownership of a file to another user of the file system (in this case either yourself or apache), and this command is only available to your server's admins. So, they essentially offered you to change the owner of the files to yourself or to apache. Your options are:

(a) If the owner of drupal's files directory is apache. then the directory can be set to 755 and apache still can read it (because if apache owns it then apache is the first digit of 755).

So, no need for 777, and the other users of your server (or even you) won't be able to write to this directory directly (only through a php script like Drupal, because php scripts write as user apache).

The downside is inconvenience: you won't be able to write into this 755 directory yourself, or to delete it, or to chmod it, except if you do it through a php script or if you ask your host to do what you want every time.

(b) If the owner is yourself you have full control of the file to do whatever you want, but then apache can write only if you CHMOD it to 777.

Your choice. I would take (b).

rtandon’s picture

rtandon commented

Although rusty has clarified all the tech things related to chown and chmod, let me put additional help - if it is.

First, you need to to know what chown is and what chmod is (perhaps you already know it as well)

chown, in simple words relates to "Who owns the file / directory etc." i.e. CHange OWNership ... right

chmod, on the other hand refers to "Who all can do what all things" - i.e. what owner can do, what his associates (in the group) can do and finally, what all everybody else can do...

Right... Now, what happens is this - You say that you own the file, directory etc... Correct, you surely do. However when the program runs, (the web server executes / parses the drupal or any other script) , the important point to note is - that it is not YOU who is doing the operations (reading / writing etc.) it the the web server (maybe Apache) ... so here is the difference. The files appears to be owned by you, (and they are) but they need to WORKED upon by someone else (apache) who is neither you, nor your group member. The necessary condition (usually) is that WEB SERVER NEEDS TO WRITE, - it's up to you to decide how you permit it.

So, what is the solution? Either you make those directories / files owned by Apache (not you) with your own rights limited to what would be the rights of the world (all users) - i.e. all other users including yourself have a limited right of viewing . chown to web server user name

Or the other alternative is, let yourself be the owner and allow all users do anything (that includes web server too) - chmod 777

Thus, there is nothing like chown 777 (unless 777 refers to user id ;)

So, either of these would let web server write to those directories, where it wants to. The dilemma has to be solved by you - the first approach is a bit more secure but perhaps less inconvenient (you may not create files, yourself for any reason, whatever it may be) and the second solution is more convenient, allowing complete freedom to all, albeit with security risk.

If the writable directory contains, temp file and not very vulnerable data, perhaps I'd go with second option (at least for the initial period)

Hope this helps.

cog.rusty’s picture

cog.rusty commented

Here is a story

When I moved to my current host, I noticed two things:

1. I found out that I could leave all directories to 755 and all files to 644 and Drupal (user apache) still could write to all of them. A very pleasant surprise.

2. I found that I had no problem CHMODing or deleting files created by Drupal (user apache). Another pleasant surprise. With my previous host, I needed to upload a php script to do these things as user apache, or to make sure that apache didn't own anything.

Looking closer, I found that those files were not really owned by apache but by myself! Apache was writing them "in my name" using some technical trick! Apparently, in case (1) , apache was reading the files "in my name" as well.

Did I like this? Absolutely! No more tricks by uploading php scripts, no more rushing to create my "files" directories myself before Drupal does, to make sure that I am the owner. And nothing was 777!

Did I feel safer since I don't need 777 any more? Not at all! The ability to do things in such a convenient way only confirmed that file system permissions mean very little in practice in a web environment. It is the host's responsibility to make your files safe from others, in whatever way.

rtandon’s picture

rtandon commented

Yes, rusty, it's possible.

Even in some shared hosting environments, by advanced configurations it is possible. However this is done by tricks such as running php as cgi or other methods e.g. virtualization or running separate instances of Apache for each domain. In smartly configured systems, it is just like that each domain owns their web server and has got most of the controls desired (with some very specific restrictions)

The above is a very generic and summary description. The detailed methods may be found on the web.

end user’s picture

end user commented

Whats happening here is the host is running PHP in CGI mode. Either PHPSuexec or suPHP. What this does is changes the uid of php and runs it as you. http://www.suphp.org

These methods have their ups and downs. I run my server with suPHP as I host other users, if this server only hosted a few of my own sites I'd run php as mod_php which has MUCH better performance then PHPSuexec or suPHP. PHP as CGI This stops exploitable php scripts from deleting files for any other user although its doesn't stop that script from deleting everything under your UID.