asked on

How to Prevent Programmers from Accessing Config Files

I am about to hire some contracted programmers to assist with some script writing. I'm giving them FTP access to a specific working directory for a sandbox URL. This is where they will do there work, but they also will be needing to do database reads. The access settings for the DB are in a config file that is hidden at a level below the public access (www) folder for that Sandbox. The structure is like this:

Public Folder: /vhosts/sandbox.com/html
Config File is at: /vhosts/sandbox.com/private/settings.php

The user FTP access is set to /vhosts/sandbox.com/html

So the user can't directly view the "settings" file, but he can reference it in an "include" statement.

As such he could also do the following to view the full contents of that file on screen.

$myfile = fopen("../private/settings.php", "r") or die("Unable to open file!");
$txt = fread($myfile,filesize("../private/settings.php"));
fclose($myfile);
print '<textarea rows=25 cols=100>'.$txt.'</textarea>';

Open in new window

Is there any way around this? Is there a way that I could allow the programmer to make use of the content of this settings.php file without having access to it?

Is it an issue of setting directory permissions (to restrict so only the server can read the file)?

How does one go about this?

Thanks.

SOLUTION

Tom Chadaravicius

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Paul Konstanski

ASKER

Something isn't clicking with me here. It's not an issue of "write" permissions to the settings.php file, it's a "read" permission. Or are you saying that if he doesn't have "write" permissions he won't be able to read that file.

Also, Linux is not my strong suite so if I were to change read/write permissions for a use, how does one do that?

If the username is "sandbox", in the above scenario, can you tell me the command I would need to issue?

username: sandbox
directory (and below) that user SHOULD have access: /vhosts/sandbox.com/html
directory (and below) that user should NOT have access: /vhosts/private

Thanks.

Tom Chadaravicius

1. A "write" permission does not spell an automatic "read" permission.
2. My idea is,
2.1. If "apache" user has the "read" permission to settings.php, the software package will run (presuming it runs as a web application under "httpd" - it may also be "nginx", "lighttpd").
2.2. The "sandbox" user will NOT be able to read "settings.php" if "sandbox" has no "read" permission.
Please give me some 30 minutes, I will set up your directory structure on my CentOS and get back.
Thank you.

Paul Konstanski

ASKER

Something that just dawned on me as well though is if the user sandbox has permissions to "write" to the public directory (as a programmer) he can then write a routine like I did to "read" the settings file as the apache Web user and display those results on the screen.

So the fact that he can't "write" to the private directory nor even "read" from the directory. As long as he can write a script that can access that directory he will have access to the config files.

Tom Chadaravicius

1.1. I have recreated directory structure, "/vhosts/sandbox.com/html/"
1.2. I have given "read" permission to file "/vhosts/sandbox.com/settings.php"
1.3. I have given "read/write" permission to "sandbox" in "/vhosts/sandbox.com/html"
The result:
2.1. The "sandbox" user can see the file "/vhosts/sandbox.com/settings.php", but can not retrieve nor read its contents.
I am attaching a screenshot.
Now, we need to allow ("read") the "apache" user to "read" the "settings.php" to be able to"include" it to PHP file.
Thank you,
Tom

Tom Chadaravicius

Sorry, the screenshot.
I've also put it here, http://www.mediamis.net/sandbox-20151028.png
*I have given "read" permission for "settings.php" for "root" only (clarification)
Thank you.

Paul Konstanski

ASKER

With the scenario you've given above, what happens if you create a file called "test.php" in your html (I assume that's your public facing directory). The file contents would be:

$myfile = fopen("../settings.php", "r") or die("Unable to open file!");
$txt = fread($myfile,filesize("../settings.php"));
fclose($myfile);
print '<textarea rows=25 cols=100>'.$txt.'</textarea>';

Open in new window

If you then access that from your server: (e.g. the equivalent of sandbox.com), what does it display on the screen? Does Apache read and display the file contents?

If Apache doesn't read and display it, then how would apache get the setting files from that file?

Tom Chadaravicius

I have set up a real website.
I gave [/vhosts/sandbox.com/html/index.php] permission "755": read, write,execute just as a normal PHP script in Apache.
Then, I gave "read/execute" permission on "vhosts/sandbox.com/settings.php" to user "apache", group "wmdoms" (numeric "550"). Group "wmdoms" includes user "apache". There's no"write" permission; and "sandbox" user can not read it as FTP user.
My "index.php"("require", "include" do essentially the same as "fopen"):

<?php

require ("/vhosts/sandbox.com/settings.php");
echo "This is index.php";

Open in new window

The settings.php

echo "This is".__FILE__;

Open in new window

The actual test can be seen here:
http:[two forward slashes]dev.avset.net/sandbox.com/html/index.php
(please replace words with slashes above; I will leave this on until November 1st).
Please let me know if this helps.
Thank you,
Tom
P.S. I don't know what's up with ExpertsExchange UI today, it does not display html editor box, sorry.

Paul Konstanski

ASKER

Thanks for ALL the great insight, but you test is doing exactly what I'm trying to prevent.

I'm trying to figure out how you can "protect" the contents of the settings.php file. This demo shows that in fact you can't.

What I'm looking for is a way that I can set up a file that apache can use to get the parameters for the databases without the programmer having access to those codes.

My guess is that the only way to truly protect the DB settings and other sensitive things I want to hide is to put them in a place that is accessed via an API call and then my script would do an external reference to it instead.

But if you have other ideas, I'll welcome them. Thanks.

Tom Chadaravicius

Dear PKonstan1:
My pleasure to be of contribution. My understanding has been, you did not want your contractors to see settings.php or its contents while using (S)FTP. I was able to hide the contents of the file "settings.php" from the contractors yet allow accessing its contents to the program ("Apache") which executes the code.
The example I have provided deliberately uses a function to dump (and thus reveal) the content of the "settings.php". If we do not dump the content, it will remain invisible - and undisclosed - to contractors.
Add <?php at the top of "settings.php", remove "echo", use an array to store host/username/password.
Thank you,
Tom

Tom Chadaravicius

I have modified the "settings.php" file:

<?php

$dbcreeds=array("host"=>"hostname.domain.net", "username"=>"tom","pass"=>"mypass","port"=>3307);

Open in new window

The "index.php" (running under "Apache") now can access $dbcreeds; the contractors can not access "settings.php".
http:[two slashes]dev.avset.net/sandbox.com/html/index.php
This is barring a contractor inserts "var_dump($dbcreeds). However, that's perhaps outside of the file system permissions scope.
IMHO, it's impossible to hide a piece of code from a developer. The company I consult/work for uses a database copy to address the issue.
Another (or concurrent) option: use /vhosts/develop (a development copy of the code) for development. A trusted person or yourself will need to copy the "settings.php" between the development and production.
Thank you for attention,
Tom

SOLUTION

Tom Chadaravicius

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER CERTIFIED SOLUTION

Paul Konstanski

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Paul Konstanski

ASKER

As I started working on this and the excellent help that Tom was giving, I realized I was kind of asking the wrong question. The blenc extension provides what I need.

I give this a "B" grade because of the track the discussion went which was different from original intent.