Permissions and PHP dev

[tork]

I do not have direct access to the server since I'm a developer using PHP/MySql on a remote shared server that uses Linux/Apache.

 

I have read that it's important for security of my web site to have the permissions on the folders and files set properly. I can change them using my ftp.

 

I am the developer. I have a number of testers who run the web app from their browsers (that accesses data files and PHP scripts and reads/writes with a db server). After testing, the app would be available to the general public on their browsers who would have the same access needs as the testers.

 

1. In the above context: Does 'read' mean reading the scripts or data files or both? Does 'write' mean taking user input and changing the data file or db content?  And what does 'execute' mean regarding scripts and data files if not to 'run' the scripts?

 

2. How do I let the server know which users are User/Owner users, which are Group users and which are Other users, in order for the server to apply the appropriate User/Owner, Group and Other permissions when these users call the web pages from their browser? (I understand the 421 read/write/execute *structure* since it's all over the internet through google searches).      

[requinix]

If it's a shared server, as in shared hosting that you get from some company online, then you don't do anything. The hosting company manages it.

[tork]

Thanks requinix. Yes, it's shared hosting. My app is high security, so I thought I'd need to handle folder and file permissions. 

 

So I take it that even though I can change permissions that I shouldn't? 

[tork]

FYI, the folder that my index.php file defaults to has permissions 775, and the index.php has permissions 644.

[requinix]

It should already be set up so that everything you create via FTP is owned by you and your group, files are created 0644, and folders are 0755. If you create things via PHP, which includes doing file uploads, then it will be a little different.

[tork]

Yes, the default permissions are as you say.

 

Here's my app structure: Scripts in PHP/MySql send text/images/videos/audios to the client and take form input from my users and write the data to DB; I send data back to them in the form of a report; The users may upload text/images/videos/audios if they wish, which I would then put in files with data about the files put into DB; The scripts then send back these files on request by the user.

 

Given that security is important with this app, do I need to change permissions anywhere with this environment?

[requinix]

Not really. If you wanted better security then you should actually move to a dedicated box - so there aren't other, untrusted users on the same machine. But you probably don't need the added security.

 

As a test of something, do a file upload through PHP and place the file wherever. This can just be a little test script you write quickly. When you look at the file through FTP, what user and group does it belong to?

[tork]

The permissions are 644. From the image file properties, the user (owner) and group have the same id.

[tork]

I notice that the uploads directory does not show permissions, whereas all directories that I have created above it do show permissions. Those that were created by the host do not have permissions. Is all this normal?

Edited April 25, 2015 by tork

[requinix]

They do have permissions, it seems you're just not able to see them. (Must be that the FTP server or client just doesn't want to show you.) Unless you're saying they have permissions 0000, which is a very bad thing.

 

PHP is running as a different user than you, meaning when it creates files and folders they will have a different owner (but likely still 0644/0755). That's something for you to keep in mind:

- If the uploads folder was created by PHP then you (via FTP) will not be able to delete or rename or otherwise affect files within that folder... unless you modify the permissions of the files/folder within PHP. But you probably don't need to do that.

- If you created the uploads folder then it'll need to be 0777 so that PHP (which is subject to the "other" permission set) can put files in there.

[tork]

Strange. I just checked the properties of the uploads folder that I created 7 hours ago, and it now shows permissions and they are 755, with the user and group having the same id.

 

To see if PHP (being subject to other) could upload the image file, I ran the upload test script again and it succeeded.

 

Should the 'no permission to write' of group and other not prevent anything being written to that folder's files except by the owner/user (being 7)? Or do I misunderstand?

Edited April 26, 2015 by tork

[tork]

Ah! I'm too fast with checking once I create the folders. I just checked a new folder 10 minutes ago, and it did not show permissions. Yet now it does; 755. I guess the server's on valerian  

[tork]

So, should the 'not permitted to write' of 'group' and 'other' of a folder or file prevent anything being written to that folder or file except by the owner/user(7)? Or do I misunderstand?

[tork]

Thanks requinix.

 

Here's a solution .. may help others ..

 

[sc]=shortcut

This is my directory structure:

root

/.config

/.logs

/[sc]public_html (points to /web)

/[sc]my web site name without the .com (points to root)

/web

:

/web/my web site folders

 

Create private folders like this:

/private

/data

/web    (URL access can only read files from this folder on down, so the 2 folders above are private)

 

Create include files in /private where they cannot be read by the browser but can include them with:

require('../private/myIncludeFile.php');

 

The data goes in /data which needs world rw access and can be opened like this (example from w3schools):

<?php

$myfile = fopen("../data/webdictionary.txt", "r") or die("Unable to open file!");

echo fread($myfile,filesize("../data/webdictionary.txt"));

fclose($myfile);

?>

 

So the calling file within /web calls the include file in /private which reads the text file in /data.

 

I tried getting the include file to run directly from the browser (not through the /web calling script) and it could not find the file. Also, I tried getting the text file from the /data text file directly from the browser and it couldn't find the file.

This is what I expected to happen because only public files under the /web folder are accessible via a url.

 

This means the folder structure makes the /web folder files safe against users who might try to gain access to /web files using uploads to /data files - hackers aside.

 

Edited April 30, 2015 by tork

[gizmola]

Tork:

Write access is your primary concern. You don't ever want world to have write access to any directory.

 

There are also many different stacks and ways that a server can be configured. In shared hosting the best practice these days is to use a fastcgi which runs php as your user. Without knowing how your host stack is working it would be easy to make assumptions that are incorrect. Some of the information you provided makes me wonder if we have the necessary facts.

 

In the old days, everyone pretty much ran apache with mod_php. Because mod_php is an apache module, it required that the apache process have at minimum RX (5) access to directories in order to run scripts. If there was a place where the app needed to write files, then typically the user's ownership was (username:username) so the only way for apache to write those files was as World/Other.

 

Thus you got lots of really insecure sites with 777 perms on directories and people managing to write .php files under the webroot for the site, and then easily executing those files.

 

Putting them outside the webroot as you are doing is correct. However, if the server is instead using a cgi config, then there is no reason for any directory to be 777 even if you are writing files into it.

[tork]

The /private and /data folders are 755. I didn't see any config files in cgi-bin (if that's what you're saying), and in the .config folder there's only a file called .keep which has no data in it (as far as I can tell).