Jump to content
TNG Community
ca_drm1n

Proper permissions for tngIL_config.php?

Recommended Posts

ca_drm1n

Quick one... my site has been working fine, but I noticed today that while the permissions on the original TNG config.php are set at 770 (rwxrwx---), the permissions for tngil_config.php were set at either 774(rwxrwxr--) or 771(rwxrwx--x) (can't remember now, as I went in and changed it to match the permissions of the original TNG config.php). Site still seems to be performing as expected with this permission mod.

1) Should the permissions be the same for these two files?

2) Should the permissions be even stricter?

My primary concern is protecting the code in files from being viewed, as these files contain the database password, username, etc.

Share this post


Link to post
Share on other sites
svoght

Quick one... my site has been working fine, but I noticed today that while the permissions on the original TNG config.php are set at 770 (rwxrwx---), the permissions for tngil_config.php were set at either 774(rwxrwxr--) or 771(rwxrwx--x) (can't remember now, as I went in and changed it to match the permissions of the original TNG config.php). Site still seems to be performing as expected with this permission mod.

1) Should the permissions be the same for these two files?

2) Should the permissions be even stricter?

My primary concern is protecting the code in files from being viewed, as these files contain the database password, username, etc.

It really varies a lot by host based on how they organize their web server and users/groups. Typically a minimum of 664 is necessary during setup, and then you can change that to 644. If the host has set things up "properly" (e.g. the web daemon is in the common group) then you can change that to 640. In theory having world 'read' permission isn't a security flaw because your host should have locked down your local folder (e.g. /sharedserver/yourname/) such that only you and the web daemon can access it and anything within.

Some hosts will also throw errors and not run any php scripts that have world write or execute permissions (xx6/xx7), because that's an added layer of protection in their fight against vulnerable and hacked scripts.

Basically I'd say try the bare minimum that still works properly on your host. In my case I can use 640, and odds are you can also use either 640 or 660. Remember that it might still load properly with 640 but verify that you can change configuration settings within the TNG admin and tngIL interfaces!

Share this post


Link to post
Share on other sites
ca_drm1n

It really varies a lot by host based on how they organize their web server and users/groups. Typically a minimum of 664 is necessary during setup, and then you can change that to 644. If the host has set things up "properly" (e.g. the web daemon is in the common group) then you can change that to 640. In theory having world 'read' permission isn't a security flaw because your host should have locked down your local folder (e.g. /sharedserver/yourname/) such that only you and the web daemon can access it and anything within.

Some hosts will also throw errors and not run any php scripts that have world write or execute permissions (xx6/xx7), because that's an added layer of protection in their fight against vulnerable and hacked scripts.

Basically I'd say try the bare minimum that still works properly on your host. In my case I can use 640, and odds are you can also use either 640 or 660. Remember that it might still load properly with 640 but verify that you can change configuration settings within the TNG admin and tngIL interfaces!

I'm not sure I understand your last sentence - "verify that you can change configuration settings within the TNG admin and tngIL interfaces". What config settings would I be changing there?

I will experiment with ratcheting it down. I checked out my host's help file on permissions, but am still fuzzy on how they work and relate to execution of php scripts when a visitor is on the site. They break the three sets into owner, group, and world, but I guess my confusion is who actually fits within these three sets. I struggle with understanding what permissions are being used as a user (logged in or otherwise) views the site with a web browser. Also not sure when the "execute" permission would ever be needed. Guess it's time to do me some google-learnin...

Maybe you can explain something else I can't quite figure out... let's say I know the url to the config.php file on the website, and I'm a bad guy and want to capture the source code so I can get the database password.

I created a dummy html page, with a single link on it, to the known url. I pull up that page in the browser, right-click the link, and select "save target as...". What stops me from being able to save that config.php file (I've tried it and can't get it to work, but am not sure why)?

Share this post


Link to post
Share on other sites
svoght

I'm not sure I understand your last sentence - "verify that you can change configuration settings within the TNG admin and tngIL interfaces". What config settings would I be changing there?

All of the options you set via the admin interface are saved into the config.php file -- that's what I mean by verifying that you can make changes (and that they then "stick".) It's easy to have a static read-only config file (400 would give you that), but it's quite another thing to be able to modify it as intended from the administrative interface, which is what I meant there.

I will experiment with ratcheting it down. I checked out my host's help file on permissions, but am still fuzzy on how they work and relate to execution of php scripts when a visitor is on the site. They break the three sets into owner, group, and world, but I guess my confusion is who actually fits within these three sets. I struggle with understanding what permissions are being used as a user (logged in or otherwise) views the site with a web browser. Also not sure when the "execute" permission would ever be needed. Guess it's time to do me some google-learnin...

On actual PHP scripts (or CGI or Perl script), the execute flag is necessary in order to tell the server you have permission to run it. The config file isn't a script so you don't need to be able to execute it... just to read it.

With regard to owner/group/world:

Owner: the creator (or uploader) of the files. Typically this is your username on your web host.

Group: there can be many uses for groups. On a web host, typically your group consists if you (see above), the web daemon (the "owner" of the web server, typicaly named "apache"), and occasionally administrative users such as your mail daemon, anonymous FTP daemon, SQL daemon, etc. This group enables your site to run all of the things you should be able to run (with the proper permissions and protections) while keeping out all the other end users on your shared server. Since the web server is the one actually doing the PHP processing, it needs to be able to access the important files such as config, which is why the group usually needs read/write privileges.

World: precisely what it sounds like -- everyone and anyone who could potentially write to the folder.

Maybe you can explain something else I can't quite figure out... let's say I know the url to the config.php file on the website, and I'm a bad guy and want to capture the source code so I can get the database password.

This is actually precisely why it's saved as a .php file wrapped by "<?php (config data) ?>" even though it's really just a collection of text and not a script -- all PHP files with the proper formatting (including this one) are rendered by the PHP processor. In this case, if you access it via hypertext transfer protocol, you end up with a rendered file, which is simply a null string because there is no output text. Try it yourself and you'll see. Alternately, if your config file was saved as .html, .conf, .txt or some other extension, it comes through as plain text and your site is vulnerable.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×