Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I've been searching for information about file/directory permissions, and I keep finding the same basic principles. What I can't find anywhere is a rationale for determining what permissions to give Owner, Group and Others. Exactly who/what falls into each of these classes? What are the implications of giving/not giving certain permissions to any of them? I'm concerned about making sure everything works properly without compromising security.

For example, I'm developing a small site on a shared host (Linux) and I would be the only person involved in the development/maintenance of it. There's nothing for viewers to download, but members are allowed to upload images through the picmonkey.com API (which a php script finalizes with move_uploaded_file). The site's files are all .php, .css, .js, .html, .jpg and .gif (although there are .eot, .svg, .ttf and .woff files associated with one font). The directories and files all have the site's username as Owner and "inetuser" as Group.

Some of the questions I have rolling around in my head are:

  • When I log in with WS_FTP, am I Owner?
  • Is a web browser an Other?
  • Do the PHP scripts themselves fall into one of these classes?
  • What permissions does each kind of file/dir need under these
    circumstances?
  • Is there a difference between read and execute on a .php file?
  • Since I have no idea who "inetuser" is, would I be correct in not
    giving Group any permissions? What if this was not the case (i.e.,
    the site's username was also used for Group - which it is on my dev
    site on a different host)?

I would be grateful for any insight anyone could give me, as well as for any recommended articles or books that would answer these kinds of questions.

share|improve this question
    
Are you more familiar with the Windows NT permissions model? In which cause, roughly, "user" = "creator/owner"; group means the same thing as in NT, except you only get one per file/directory (is the other name which, e.g., ls -l shows) (well, you can have multiple if you have ACL support enabled, but, ignore this for now); other = "everyone". –  derobert Aug 29 '12 at 4:25
    
No, I'm not familiar with Windows NT. –  user1157244 Aug 30 '12 at 1:03

3 Answers 3

You seem to understand the concept of permissions, but I think you're getting caught up on user/group/other and what those mean in various contexts.

Briefly,

  • A user is an individual POSIX account
  • A group is a logical grouping of multiple POSIX accounts

A file on disk has two owners. The user owner and the group owner. For any particular file, other is any user account that does not match the user nor is a member of the group. In other words, other is any user that is not the user owner and is not a member of the group owner.

Further, each process runs under a specific User ID (or UID), and is a member of one or more Group ID's (GID). Use the command ps -ef (on Linux and Solaris, or ps -ej on OS X or *BSD) to see the user executing each process. You'll see that apache and ws_ftp are also being executed by users.

When a process tries to access a file on disk the following happen:

  • If the UID of the process matches the user owner of the file then user permissions are enforced.
  • Else, if any GIDs of the process match the group owner of the file then group permissions are enforced.
  • Else other permissions are enforced.

To answer your questions specifically:

When I log in with WS_FTP, am I Owner?

Technically yes, because there is always an owner, but it depends on your definition of "I".

If you are logging in as a real POSIX user on the system then files you create/access will be as the user you logged in as. If you logged anonymously then the files you create/access will be that of the UID of WS FTP. This will likely be either ftp or nobody.

Is a web browser an Other?

The web browser is not anything because it's not being executed on the server. But the browser accesses a web server. The web server is running as some specific user (just like WS_FTP is). That user is likely www-data, apache or nobody.

Do the PHP scripts themselves fall into one of these classes?

PHP scripts are executed by the scripting engine module of the web server. They will be executed as the same user running the web server.

Is there a difference between read and execute on a .php file?

Yes. Read means that the user can read the contents of the file. Execute means that the contents can be run as a full fledged process.

Since PHP scripts execute inside the scripting engine of the web server (i.e., they are part of the memory space and execution thread of the server) they do not need to be set executable.

Since I have no idea who "inetuser" is, would I be correct in not giving Group any permissions? What if this was not the case (i.e., the site's username was also used for Group - which it is on my dev site on a different host)?

inetuser is a user account on the system, just like your account. It may also be a group. Hopefully you can answer this question yourself after reading through this.

What permissions does each kind of file/dir need under these circumstances?

Generally, you want data files to be owned by user accounts that are used by actual humans (i.e., you). In other words, your web content should not be owned by the apache user.

  • User permissions should almost always be rw- for data files or rwx for directories and programs.
  • Group permissions should usually be r-- for data files or r-x for directories and programs. If you want members of that group to be able to write to those files then it should be rw- and rwx.
  • Other permissions should almost always be r-- for data files and r-x for directories and programs or --- if you want to deny all access.
share|improve this answer
    
Thanks! There was some helpful info here (although, since I'm no techie, I'm not sure I understood it all). I tried the ps -ej command, but all I got was a long list with the column headings PID, PGID, SID (all numbers), TTY (mostly ?) TIME and COMMAND. No sign of the user names or the apache or ws-ftp processes you mentioned. What should I be seeing? –  user1157244 Aug 30 '12 at 3:26
1  
I need a little clarification of the terminology in your last answer. Are .php files considered "data files" or "programs"? –  user1157244 Aug 30 '12 at 3:57
1  
Technically speaking, I would say it's a data file. The program is the PHP processor module in the web browser. –  bahamat Aug 30 '12 at 17:44
    
About ps, I was looking at the man page on my Mac. Sorry about that. On Linux use ps -ef to see user names. –  bahamat Aug 30 '12 at 17:46
    
All of my directories are being set to 705 by default, and all files (no matter what type) are being set to 604 by default. Everything seems to be working fine. Is it OK to leave them all like that, or are there potential problems I should be aware of? Also, why do you disagree with DavidKohen's statement that scripts should have execute permissions? –  user1157244 Aug 31 '12 at 8:34

OK, lets put some light on the very basics of file permissions, and then we will move to your specific case.

Permissions

The basic file permissions are:

  1. r ead - gives the ability to read the content of a file.
  2. w rite - gives the ability to write to that file.
  3. e x ecute - gives the ability to execute a file or a script.

In case of directories the names are the same but they have slightly different meaning:

  1. r - gives the ability to read the names of files in the directory, but nothing more.
  2. w - gives the ability to create a file in the directory or write into a file that already exists.
  3. x - gives the ability to read the content of a specific file in the directory, but does not allow to list the files in it (you need read permissions to do it). It also allows to change (cd) into this directory.

Users, groups and others

Every file and directory have the attribute of an owner and a group. You can check them by invoking ls -l command or by looking at indicators in a software like FTP client. Let's see an example:

-rwxr-xr-- 1 jdoe zeppelins  0 08-29 21:50 example_file

Here you have a file named example_file, that was created at 21:50 on 29-08, and has length of 0 bytes. Its owner is an user with name username, and it belongs to a group zeppelins.

Now lets look at the file permissions -rwxr-xr--.

  • The first character indicates a file type - single dash - means that it is a regular file (not a link or a directory).
  • Next triad rwx indicates that user jdoe can read, write and execute this file.
  • Following r-x means that all members of group zeppelins can read and execute, but not modify this file
  • Last, r-- indicates that users that are not jdoe and do not belong to group zeppelins can only read this file.

Now back to your case

  1. When you log in via WS_FTP you are identified as an user with username you provided at login. You can be the owner of some files, but you do not need to (there may be files that have other owner specified).

  2. Web browser does not access the files. What accesses them is web server, which reads the file and then feeds your browser with its content. Webserver can run under names like apache httpd or similar, but if you are using a hosting, it can as well identify itself as inetuser. If it is not the case, it accesses the file as other user.

  3. PHP scripts should be readable and writable by the person that modifies them (most probably the owner), and readable but not writable by web server.

  4. For a simple PHP script edited by jdoe, under assumption that webserver runs under webserver name, appropriate permissions would be -rwxr-----. In some cases it may also be need to be readable by some other users - in this case -rwxr--r-- may be more appropriate.

  5. For a PHP file read permissions are enough.

  6. Best idea would be to make a quick test - remove all permissions for group for a specific file, and check if you can still access it. My bet is that inetuser is an alias for webserver, and so your files should have the read access for this group.

  7. For uploading files you should create a separate directory, with no read or execute rights, but with write access.

share|improve this answer
    
Thanks! The first two sections were the stuff I already knew, but the last section was helpful. It sounds like I need to figure out whether the webserver runs as an inetuser Group user or an Other user and set permissions accordingly. What Other users might need to be able to read the PHP scripts? –  user1157244 Aug 30 '12 at 2:12
    
Adding read access for 'other' might be necessary in case where the webserver does not run as 'inetuser'. –  gorkypl Sep 2 '12 at 20:42

The permissions in Linux do not work according to the software in use, as it sometimes does on Windows (services install themselves with specific permissions). In Linux the program that tries to read/execute files/directories is running as a specific user, that could be different in a shared environment.

About scripts, the user that the web server runs with must have execute permissions, otherwise the end user will see the script and not run it.

Some web servers run with the user www-data, but as this is a shared environment, odds are this is different in your case and you should contact your provider to check.

If you know which http server you are running under and have shell access you can run:

ps -ef | grep <server>

On the first column you should see the user the server is running under, it could be the same user that you are logging in with.

Keep in mind that in a shared server, there may be more than one server running at the same time, and you will have to figure out which one is yours.

The FTP client you are using does not affect permissions, it is dependent on the user you are logged in as, but this may be different from your login username.

A web browser is not an entity in this scenario, only the web server is, and as I mentioned before, it is running using it's own user.

As a rule of thumb, for public areas of your website I would give execute permissions to user, group and other on scripts and directories and read permissions on other files.

If you have a directory to which the web server is supposed to allow creation of new files, the directory should be owned by the user the server is running under or with write access to all and directory sticky bit (t).

share|improve this answer
    
Thanks! I think I'm starting to understand how this all works. How would I determine which http server I'm running under? –  user1157244 Aug 30 '12 at 2:34
    
gorkypl and bahamat say that PHP scripts do not need to be executable, but you say they do. Why the conflicting advice? –  user1157244 Aug 30 '12 at 3:11
    
The conflicting advice is due to assumptions the others have made, that the php runs as a fastcgi or using a php engine, however, in some hosting providers it still uses an old CGI method that requires execute permissions. If everything works without execute permissions, then you do not have to set the execute bit, if you run into problems of seeing the scripts rather than their output, I would try to grant execute permissions. –  David Kohen Sep 2 '12 at 11:08

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.