Jump to content

Permissions and PHP dev


Recommended Posts

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

Link to comment
Share on other sites

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? 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by tork
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by tork
Link to comment
Share on other sites

Thanks requinix.


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



This is my directory structure:

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


Create private folders like this:

/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:



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

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


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 by tork
Link to comment
Share on other sites


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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.