Permissions on a typical shared Linux web host

I am trying to understand the file permissions on a typical shared Linux web hosting account. I know how to set rwx permissions for the OWNER GROUP and PUBLIC entities of a file or directory. What isn't very clear to me is, typically where would the access permissions map to? I am guessing that:

USER permissions would affect what ... uhm... not sure here
GROUP permissions would affect what a PHP or other script running on the server could do
OTHER (sometimes called PUBLIC or WORLD?) permissions would affect what a UA of a web site visitor can do

Can anybody correct, confirm or expand my understanding on this?

CLARIFICATION:

If I want to allow my PHP script that run on the server the permission to write to a file, would that permission be specified in USER, GROUP or OTHER? If I want to deny a website visitor's browser to see the contents of a directory, would that permission be specified in the dir's USER, GROUP or OTHER?

Let's specify some keywords fists.

FTPUSER   = you with your ftp client
WWWDAEMON = program (servers) that's responsible for processing your web pages and scripts 
WWWUSER   = user as which the WWWDAEMON processes your pages
BROWSER   = Someone looking at your website with a browser
FILES     = files that reside in your www/ftp site
yourgroup = group that your FTPUSER belongs to and WWWUSER does not

You access your FILES as FTPUSER with a ftp program

-rwxr-xr-x  2 FTPUSER yourgroup   72 2012-01-18 13:56 somescript.php

Now.. becasue WWWDAEMON user WWWUSER is not you (FTPUSER) it respects OTHER permissions when it tries to read your script. (There are hosting site's that run your scripts as your FTPUSER). Removing the other read and exec permission will block use of somescript.php

# this scipt is unusable trough a browser
-rwxr-x---  2 FTPUSER yourgroup   72 2012-01-18 13:56 somescript.php

Creating a directory with world writeable permissions will allow your script to write there, but unless you protect that directory somehow (like with .htaccess or put it outside your www dir) it might also mean that the BROWSER can access those files directly, because:

BROWSER contacts WWWDAEMON which runs as WWWUSER so 
BROWSER can see everything processed by WWWDAEMON that the WWWUSER can. 

Processed also means that WWWDAEMON also respects .htaccess or similar to block access.

The advice is to create say phpwritedir and give it a+rwx rights. Add .htaccess file there (if your hosting service allows it)

deny from all

Whit this your script run as WWWUSER can still use that directory, but WWWDAEMON will block any BROWSER access to it.

You got it pretty much mixed up.

ugo ugo is user, group and other - not owner. Owner is the user, usually holding the most rights.

GROUP permissions would affect what a PHP or other script running on the server could do

Group permissions don't affect what can be done (read, write, execute), but who can do it. The same for the user:

USER (sometimes called PUBLIC?) permissions would affect what a UA of a web site visitor can do

The user is the owner, but o is used for other, which is what you call public. And again - it is who can do, not what can be done.

You can use the abbrevations ugo when using chmod, which is more easy than the numerical codes:

  chmod ug+w sample1
  chmod go-r sample2 
  chmod g=w  sample3 

• sample1: add write permissions to user and group
• sample2: remove read permissions from group and others
• sample3: set group permissions to write

Every file is owned by a user and a group. See them with ls -l. Example:

ls -l /var
insgesamt 12
drwxr-xr-x  2 root root   592 2012-01-12 08:02 backups
drwxr-xr-x 28 root root   776 2011-08-18 05:12 cache
drwxrwxrwt  2 root root    48 2010-06-22 01:46 crash
drwxr-xr-x  2 root root  3704 2010-06-05 22:01 games
drwxr-xr-x 84 root root  2296 2011-10-16 13:25 lib
drwxrwsr-x  2 root staff   48 2007-10-08 12:47 local
drwxrwxrwt  3 root root    80 2012-01-19 08:03 lock
drwxr-xr-x 22 root root  5992 2012-01-19 08:01 log
drwxrwsrwt  2 root mail    72 2012-01-18 07:56 mail

A part of the listing of /var. Most directories (d...) belong to root.root which is as well an user, as a group. However, mail and stuff are groups, which aren't identical with the user.

update (after the update of the question):

If I want to allow my PHP script that run on the server the permission to write to a file, would that permission be specified in USER, GROUP or OTHER? If I want to deny a website visitor's browser to see the contents of a directory, would that permission be specified in the dir's USER, GROUP or OTHER?

Well - it is not the permission of a script to do this or that. It is always the permission of the user who runs the script.

To run a script, the user must be able to read it, which means, it is read from disk to put it into memory, to execute it. You can't execute it, without reading it.

To write to a file, the user has to have the permission to write to a directory - not the script or program.

If the program, writing to a directory, is a server, it is typically not started from an anonymous user in the web, but from a special user like 'www'.

Because you talk about shared hosting, let me just add some fun details about a shared hoster I often work with. From my experience, a setup like this is not uncommon in shared hosting environments.

In shared hosting environments, it is not unusual that there are several users sharing the same host with you. Naturally, they all have user accounts.

My user account may be 123456-user1. Now what is done is, my primary group is set to nobody or nogroup, so that all new files and folders I spawn belong to 123456-user1:nobody.

They don't just throw all users on the host into the same primary group for security concerns I would assume.

So now I can read my files, no group can read it (cause, well, the group is nobody), how does Apache even read it?
Apache reads it by running an instance under your own user account. For example, with PHP, it would run in CGI Mode to execute files under your account.

So the first octet of the permissions is what's relevant for the whole system. It defines what both you and website visitors (so to speak) can do to the file. The group can be ignored. And the last octet for others is somewhat equivalent to the owner part.