The only way to get the file, other than as a local user, is via some sort of file transfer. Methods of file transfer (and indeed, any other form of remote communication with the server) are labelled with "Port numbers", identifying which service (if any) on the machine should handle the communication. By default, requests from browsers to webservers come in on Port 80, so if a request comes through labelled "Port 80", the TCP/IP stack of the server will redirect the request to Apache - simply because that is what it is configured to do with requests labelled "Port 80" (the TCP/IP stack doesn't even know or care what happens to the request after that: Unix is completely modular, and, in fact, Windows systems are identical, in this respect, since they use a copied version of the Berkley Unix TCP/IP stack - same as everyone else).
Apache will respond to requests made of it in whatever way it is configured to, and send the response back via "Port 80". Out will go the reponse, back the way it went, with the TCP/IP stack labelling this as a "Port 80" response.
In fact, to see what a browser is actually doing, do this:
1) Open a DOS window or terminal emulator (depending on what OS you are running on your desktop).
2) Type in:
telnet
www.google.com 80
Hit return, and you will connect to one of Google's clluster of web serving machines using port 80.
3) At the telnet prompt, type in:
GET / HTTP/1.0
(You may not see anything in the tenet box if you're on Windows, because Windows defaults to "local echo" off, but keep typing - the machine at the Googleplex will be recieving the text, even if you can't see anything on your machine. In fact, change this setting on the windows client by using the Terminal>Preferences option, if you like)
4) Now hit carriage return twice.
Result?
Blurgh! A whole load of HTML: Google's front page, in fact. Now, that page is a PHP page, but all you get is the output. Congratulations, you just experinced a moment in the life of a web browser :). That is exactly the set of signals sent from your browser when it makes a request to
http://www.google.com/. "GET", followed by a space, followed by the name of the page (in our case a page of "/" - i.e. whatever the webserver is configured to hand out from its root web direcory) another space, and the protocol, followed by a forward slash, the protocol verion number and two line feeds. That's exactly the sequence of characters a web browser sends. It sure ain't rocket surgery, is it :)? Try connecting to p2p.wrox.com on 80, and GET /forum.asp?FORUM_ID=90 (make sure you specify HTTP version 1.0, not version 1.1, or it throws an error page back at you - but, hey, it's still a page). You'll get the HTML output for the homepage of this forum, delivered to you from from the p2p webserving machine. That's an ASP page, Google's was a PHP page, but you won't see and "Response.Write" or "echo" nonsense, in either case, because exactly the same basic process is followed on both machines, as I outlined earlier. The splurge of HTML sent back, in each case, is exactly what your browser gets back. Although telnet's standard port is 23, we actually specified port 80 in our connection request, turning telnet into a rather crap web browser, in the process. A real browser parses the markup as it comes in, of course and finds HTML elemnets like <img src=...> and makes separate requests for these images, as well, but since we're using telnet, I don't think we'd be able to recognise the images if we requested them (although the server
would send them). Does the webserver care? No, it doesn't, but the server logs in each case now contain a curious request entry.
Now, users
can do the same thing in reverse with a web browser. they can make a request of another port using any standard web browser (or, indeed, telnet, if they're masochists), simply by appending the port number to their request after a colon. And indeed, it is fairly standard practice for specialist webcontent to be handled on a "high port" (a "port" with a number above 1024 by) configuring the webserver, and any firewall in between, to handle such requests as legitimate web traffic (on Apache, we specify this with a Listen directive, specifying the actual network interface such request can come in on). Example of this, are the Epicmodem-chipset routers, popular for getting people onto broadband connections throughout Europe. These have an embedded operating system that runs a webserver (a hacked copy of Apache, in fact) that handles administrative traffic on a high port. Similarly the IDE-slot FlashROM-based Linux servers that Kyzo sell, use the same principle, running two entire Apaches - one outward facing and delaing requests on Port 80, as per normal, and one on the inward (LAN-facing) network card, dealing admin requests on a high port. The user simply has to know that they must append the high-port-number to all the requests they make via this channel by appending a colon followed by the port number to the request in the addressbar of their browser.
However, if there is nothing that can respond to those requests at that port, then they can make all the requests they want, and they will fall on deaf ears, so the speak.
All that said, why do you want your PHP pages to be given 777 modes, anyaway? LIke I said originally, the users never actually get to read the file: it is the web server's user that actually reads the file (and in fact, the best configuration to use, is to configure the wbeserver to run as "nobody", since that way they can only run or run anything marked as available to
anybody.
The user never gets sent the
actual file, they get sent a copy of the file. And if the webserver is configured to pipe every PHP file through the PHP parser first, then all they get is a
copy of the parsed output... So the only user that ever gets to rad the
actual file is "nobody". "nobody" doesn't need write access to the file, since the one thing a webserver never does is write files (yes, PHP can write files, butt hat's a different user again - or should be).
So, to answer your question. If you give modes 777 to all your web files, will Apache give a Monkey's? Answer - No. Will other users be able to change and moddify those files: it depends - if you've left port 23 open, they'll be able to telnet in and edit to their heart's content, yes, becaues - even if they're loging in remotely - they are actually running on a command line as if they were local users. If you've closed off 23, but left port 22 open, they'll have to use a secure shell client, like PuTTY, but they'll still have as much access as if they were sitting typing away at the server. Either way, they'll have to have the login details for at least
someone on the system before doing so, because they'll have to get a command line prompt, but as soon as they have, they'll be able to muck around with the files as much as they want, because by specifying 777, that's what you're saying they can do.
In summary, is there any advantage I can see to giving 777 mode to web files? Answer: none that I can see, no, and a whole host of reasons not to - but its your call :).
chmod
