Couple Apache Problems

[HiImNew]

So I've recently switched over from shared hosting to vps hosting and starting a server from scrath.  Transitioning has come with some troublesome problems that I can't find a solution for anywhere.  I've been searching for the past couple days on and off but can't find any other solutions that match my exact criteria.

 

So.  What I've got:

 

1.  File permissions are not working how they used to.  Before, all I had to do was set a file to 0640 and it would serve an HTTP 403 server code when viewing it in the browser, but could still be accessed through PHP.  Now, If viewed in the browser, it issues a PHP error:

[13-Aug-2016 18:18:41 America/New_York] PHP Warning:  Unknown: failed to open stream: Permission denied in Unknown on line 0
[13-Aug-2016 18:18:41 America/New_York] PHP Fatal error:  Unknown: Failed opening required '/var/www/html/inc/init.inc.php' (include_path='.:/usr/share/php:/usr/share/pear') in Unknown on line 0

As well as not being accessible through PHP (i.e. require()); same error.  Now, that is with the owner/group of root root.  If I create the file through FTP which gives an owner/group of root www-data it displays in the browser and is accessible through PHP with 0640???  Perhaps an ownership rights issue?

 

2. Fopen is failing when creating a file giving an error of:

[13-Aug-2016 18:31:12 America/New_York] PHP Warning:  fopen(progress.txt): failed to open stream: Permission denied in /var/www/html/***/process.php on line 31

When creating a file through PHP, the owner/group is www-data www-data.  The directory has 0755 perms and is still giving a permission denied prompt?  Another ownership rights issue I'm suspecting.

 

Not looking for an all-out solution.  Just any advice would be appreciated!  I'm not sure about what information to provide.

[Jacques1]

When the owner of a file is root:root and the permissions are set to 0640, then by definition nobody other than root can read the file. This is how Unix permissions work and have always worked.

 

In general, scripts should never be owned or writable by the webserver, because this makes them vulnerable to malware infections. They should be read-only. Set the owner to root, the group to www-data and the permissions to 0740.

 

 

The directory has 0755 perms and is still giving a permission denied prompt?

 

5 means read + execute. You need write + execute, i. e. 3. But don't allow the webserver to create files within the main application directory, because this again can lead to the injection of malicious scripts.

Edited August 13, 2016 by Jacques1

[HiImNew]

Thank you for the response!

 

I have done as you said, setting it to root www-data and giving the permissions of 0740, but it still will not serve a HTTP 403 error when viewing through the browser (I probably should have explained a bit further).  It will still be accessible for viewing through the browser.  Is there a way to serve a 403 error through the browser but still allow PHP to access it?  Such as if I wanted a zip file not to be hotlinked (Without the use of htaccess) but still be able to download through PHP like my old server had it.

 

Files are unable to be created on the server unless I give the directory 775 permissions, which I reaaaallly don't want to (And probably shouldn't?) do.  The directory is root www-data.

[Jacques1]

If you don't want to make a file publicly accessible, don't put it into the document root at all. There's no reason why the user should get anything other than a 404 code. This 403 hack is nonsensical, risky and complicated (you'd have to run the webserver and PHP under two different accounts or mess with the webserver configuration).

 

 

 

Files are unable to be created on the server unless I give the directory 775 permissions, which I reaaaallly don't want to (And probably shouldn't?) do.  The directory is root www-data.

 

Creating files in a directory requires execute + write permissions (numerical: 3). So you don't need anything more than 0730.

 

When you need to create files dynamically, this should happen outside of the document root in a separate directory to prevent code execution and manipulations of the application itself.

[HiImNew]

If you don't want to make a file publicly accessible, don't put it into the document root at all. There's no reason why the user should get anything other than a 404 code. This 403 hack is nonsensical, risky and complicated (you'd have to run the webserver and PHP under two different accounts or mess with the webserver configuration).

I was just wondering if it were possible.  It's not a file going into the document root, but it is being downloaded through a "self-served" API which the user could intercept the filename + location from.  Nothing more than an inconvenience really.  Will just work around and serve a temporary mirrored location.

 

 

Creating files in a directory requires execute + write permissions (numerical: 3). So you don't need anything more than 0730.

 

When you need to create files dynamically, this should happen outside of the document root in a separate directory to prevent code execution and manipulations of the application itself.

I'm not getting away with anything but 0770 permissions it seems.  730 is creating a RecursiveDirectoryIterator fault:

[13-Aug-2016 20:29:05 America/New_York] PHP Fatal error:  Uncaught exception 'UnexpectedValueException' with message 'RecursiveDirectoryIterator::__construct(/var/www/html/***/DirectoryName): failed to open dir: Permission denied' in /var/www/html/***/DirectoryName/functions.inc.php:35
Stack trace:
#0 [internal function]: RecursiveDirectoryIterator->__construct('/var/www/html/a...', 0)
#1 /var/www/html/***/DirectoryName/functions.inc.php(35): RecursiveDirectoryIterator->getChildren()
#2 /var/www/html/***/DirectoryName/process.php(108): file_search('test', false, 'progress-1.txt')
#3 {main}
  thrown in /var/www/html/***/DirectoryName/functions.inc.php on line 35

Only way of fixing it seems to be giving Group Read rights to the directory

[Jacques1]

I was just wondering if it were possible.  It's not a file going into the document root, but it is being downloaded through a "self-served" API which the user could intercept the filename + location from.  Nothing more than an inconvenience really.  Will just work around and serve a temporary mirrored location.

 

Many things are possible, but I still have no idea why you need or want this odd approach for your API.

 

In case my suggestion wasn't clear: You put your files into a directory outside of the document root, then your API serves the contents, ideally with X-Sendfile. Now the files cannot be accessed directly, because they don't exist in the document root, but they can be accessed through your API.

 

This also allows you to completely hide any path information. You can use numerical file IDs or just the filename or any identifier you want.

 

 

 

730 is creating a RecursiveDirectoryIterator fault:

 

Now you're talking about a different task. If you want to list the directory content with an iterator, you indeed need read access. Previously, you asked about writing files.

[HiImNew]

Many things are possible, but I still have no idea why you need or want this odd approach for your API.

 

In case my suggestion wasn't clear: You put your files into a directory outside of the document root, then your API serves the contents, ideally with X-Sendfile. Now the files cannot be accessed directly, because they don't exist in the document root, but they can be accessed through your API.

 

This also allows you to completely hide any path information. You can use numerical file IDs or just the filename or any identifier you want.

 

To put it simply, I offer a download to users.  That download has the ability to update automatically through my API in which it downloads the patch files directly off the site.  Originally I had it so that it would give the link to the file directly through communications.  But I will change that so it serves it instead from the API request landing page or through a temporary mirror.

 

Now you're talking about a different task. If you want to list the directory content with an iterator, you indeed need read access. Previously, you asked about writing files.

 

My bad for the lack of explanation.  The one file does both.  Creates a progress file and scans all of the system files.  Unrelated to the aforementioned API.  I take it that means I have to stick with 770?

[Jacques1]

I take it that means I have to stick with 770?

 

Yes, which is not a problem for an isolated "offline" directory.