Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question

3 Answers 3

up vote 2 down vote accepted
+50

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.

share|improve this answer
    
Excellent! Someone who understands my question and a very clear and helpful answer. –  JannieT Feb 14 '12 at 10:01

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'.

share|improve this answer
    
Thank you for clarifying the name confusion. My FTP program (Filezilla no less) uses OWNER, GROUP and PUBLIC and I didn't know this wasn't the proper Linux names. I'll edit my question to avoid confusion. I think the other information in your answer isn't relevant or I am still missing soemthing big here. –  JannieT Jan 19 '12 at 10:54
    
So, you are saying (in a rather round about way) that typically on a shared hosting setup, the USER permission affects what the PHP script running on the server can do, right? And so in that case, unless there is a very special scenario, the GROUP permission should not be more constraining than the USER setting, right? What about a visitor's browser permissions? Is that equal to OTHER? –  JannieT Jan 19 '12 at 17:48
    
Last question first: The users browser runs on a different machine and is in no way of influence. The server does not even know, what permission the user on the remote machine has, and what username is used over there. –  user unknown Jan 19 '12 at 19:14
    
There is no overall user-permission. The first question is, who is the user, running the PHP-script? This will depend on the server, which is used and its configuration. Servers are mostly started at startup via init-scripts, which means, with root permissions, but root may start them in the name of a third user, like www or www-admin or something. In normal cases the installation will take care of this, and you won't modify permissions of files manually. However, read the manuals of your server and the README files. –  user unknown Jan 19 '12 at 19:29
    
Picture starting to get clearer here. So you are saying no matter how the server is configured (special users, apache etc.), the file and folder permissions can in no way affect the access permissions of a visitor's browser? If I want to control browser access I need to use .htaccess files or obscure folder names etc. –  JannieT Jan 20 '12 at 6:40

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.

share|improve this answer
    
Thanks, Oliver. Very clarifying real example –  JannieT May 31 '12 at 14:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.