777 permissions

[Serra]

Wow, I just found that my installs of SnippetMaster has directories that are set to 777 by default and that resist being changed to a more reasonable setting, such as 655. 

Why would I want ANY directory on my system to be set to 777?  That is just stupid.  Why should I allow everyone on my server access to my snippet master database?  Do other people on my server actually need access to my database?  I mean is there a guy on my server that is using it?

I'm fairly upset that I purchased licenses for a software who's developer uses 777 permissions.  I'm fairly sure that I'm going to have to abandon this software and find another solution.  If the posts on this support forum are any clue, it appears that this is a known issue and that it is not being addressed.

[admin]

Hello,
 
The documentation is very clear that "write permissions" are required for any files you wish to be editable with Snippetmaster.
 
http://www.snippetmaster.com/documentation/

You can move the snippet-db folder "above" your web root to help protect it, but yes, it requires "write" permission so that SnippetMaster can read to it.

This is pretty standard for any server-side software that needs to write to a file.
 
There is no way around this "problem" if you want to run any kind of server-side program to manage your website files.  (ie: This is not an issue specific with SnippetMaster.)  Any program that you run on your web server will need to have "write" permissions for the files you want it to be able to modify.
 
First, it's important to note that your files are not "insecure" just because they have permissions of 777.  Your files are *only* insecure if there is some other script or program on your website that allows a hacker or someone to edit your files.  Simply have a file with "write" permissions does *not* mean anyone can change the file.  They would still need access to a program on your server (like SnippetMaster) that can change the file.
 
Second, there are a few different methods of allowing a server program like SnippetMaster to write to your files, without requiring 777 permissions.  For example, all our own servers (I own a web hosting company) use something called "phpsuexec", which causes the server program (Snippetmaster) to actually run as your own account user. This way, it can write to your files without them having to have 777 permissions.  You should check with your web hosting provider if they offer this capability.  If not, you're welcome to check out our hosting packages -- www.etwebhosting.com

Third, your web hosting provider should be blocking other people on your server from being able to see or access files in YOUR account.  This is easily done with something called "basedir_restrictions", and is standard for just about every hosting company I know.  If your host doesn't include this security restriction, then you should change to a better provider immediately.
 
I'm not sure what else to say here.  If you'd like a refund, let me know your paypal transaction ID and I'll refund your payment and cancel your SnippetMaster licenses.
 
It's worth nothing that SnippetMaster is used by about 50,000 people right now, and I have not had any reports of a "777" file being hacked through Snippetmaster.  Of course, there is a risk that your "writable" files could be accessed by some other program on your website or server, but this is 100% out of my control or anything to do with Snippetmaster.

Lastly, if you can think of a way to allow a PHP program (SnippetMaster) to access your files without requiring "write" access, then please let me know.  Otherwise, this is a pretty basic restriction and requirement for using a web-based software to manage files on your website.
 
Sincerely,
 
Henri Straforelli
 
Also -- please point me to the threads in the forums where you claim this issue is not being addressed.  Thanks.

[Serra]

Do a search for 777 permission and you will see NO discussion of the security risk that this poses. 

This is basically the response I emailed you to your claims:  (I edited out a few things that don't apply to this discussion)


You are incorrect about the permissions.  On my system, snippet master would be able to write to directories that have 655 permissions, 777 is not required.    I use PHPSuExec, which allows Apache to run inder CGI, so each user's processes run under their own ID, not under nobody.  This gives the system a much higher level of security and allows processes running for a specific user to open, read and write to folders with 655 permissions.

Your program is faulty in that it requires 777 permissions instead of checking to see if write access is available.   I routinely write code that accesses read/write/create in folders and I never, ever, use 777 permissions and I do not allow them on my system for security reasons.

You are also incorrect about 777 permissions.  They are not only insecure if a hacker can exploit code on the site.  They are also insecure in that anyone on a shared machine with a 777 directory is allowing access to everyone on that system.  Not all hosts use open_basedir, because of this, those systems allow users on the system to access other user's 777 folders.

You are correct that your documentation says that 777 is required, however, I never used the manual installation, so I didn't bother to read how to install it manually.  Also, many program say they require 777 directories to avoid confusion, but in reality, they will accept 655 directories on PHPSuExec systems because they check for write access, not permissions.

I understand that this appears to be all new to you, as your position seems to be that a user can't write to a 655 permission folder.

Thank you for responding to my query.  Customer support wise, you are top notch.   Thank you.

[admin]

Your program is faulty in that it requires 777 permissions instead of checking to see if write access is available. 

Actually, you are incorrect. Permissions of 777 are not required.  In fact, on my own test server I am using phpsuexec and no files have 777 permissions -- snippetmaster works just fine.

For your info, here is the function I am using within snippetmaster to test if a file is "writable" or not:

Code:

function isFileWritable($file) {

if ($file) {
if (is_writable($file)) { return true; }
else { return false; }
}
else return true;
}

You'll note, that this uses the standard "is_writable()" PHP function.  If the file is writable to the PHP script, then it is true, otherwise it's false.  If your system is set up to allow write access with something other then 777, then it should work for you.  If it doesn't, then either your system is not how you think it is, or there is a problem with the PHP software itself.

 I routinely write code that accesses read/write/create in folders and I never, ever, use 777 permissions and I do not allow them on my system for security reasons.

Like I said, Snippetmaster does not care if you have 777 permissions or anything else.  It merely checks if the file is writable.  If so, then it works.  If not, then an error is displayed.  It's up to you how you want to give the PHP software (SnippetMaster) permission to write to the files.

  They are also insecure in that anyone on a shared machine with a 777 directory is allowing access to everyone on that system.  Not all hosts use open_basedir, because of this, those systems allow users on the system to access other user's 777 folders.

  I'm not sure what you want me to do here.. if someone is using a web host that does not use open_basedir restrictions, then I can't do anything about that.  It's your choice to use such a host or not.  I highly recommend switching to a better provider if your host does not use open_basedir restrictions.

Also, SSH access to your files should be restricted through jail shell.  The same issue applies here. If your hosting provider allows other accounts to access files in YOUR account, for any reason, then your hosting provider does not know what they are doing, and you should switch to a better provider. 

I understand that this appears to be all new to you, as your position seems to be that a user can't write to a 655 permission folder.

This is not my position.

 My position is that there are too many variables to say that a file needs "777" or "666" or "655" or whatever. 

I am saying that any files you desire to be editable by SnippetMaster need to be writable by the SnippetMaster software (PHP) running on the server.  However you do this, is up to you.  (And I recommend using a hosting provider that does this as secure as possible -- with phpsuexec.)

[Serra]

When I change the snippet-db directory to 655, I get the following error message.

Code:

I was not able to open the database folder specified in your db.inc.php file. (/home/poetrize/public_html/snippet/snippet-db/67001170d0) Either the folder does not exist or it does not have enough read permissions.

You should fix this problem and then go through the installation wizard again.

Instructions To Restart The Installation Wizard:

1. Open your db.inc.php file and delete the contents.

2. Reload this page (click refresh in your browser) and the program will automatically detect that it needs to be reinstalled.

The permissions are as follows:

Code:

drw-r-xr-x   3 poetrize poetrize  4096 Mar  1 08:30 snippet-db/

I'm I misreading that error message?  All I did was chmod snippet-db from 777 to 655.    From the code you posted, I would assume that that code would still work on my system under open_basedir and PHPSuExec.

[admin]

All I did was chmod snippet-db from 777 to 655.    From the code you posted, I would assume that that code would still work on my system under open_basedir and PHPSuExec.

Hello,

Yes, it should still work as long as the "is_writable()" function works.

Hmmmm...  can you give me a bit of time to look into this in more detail?  To be honest, I'm falling asleep on my feet here after an all-nighter trying to manage something for my business. 

I'm going to get some sleep for a while, but this is a high priority for me to investigate once I am back awake.

What I'll do is take a look at this specific section of code and make sure there is nothing screwy in there, and then work with you to get it resolved.

[admin]

Shucks, I love a good challenge, so I already started looking into this.  Sleep is over-rated.

From the error message you provided, I think this is being generated by the /includes/config.inc.php file.  It is trying to check and make sure your db folder is valid.

Here's the full code from the function:

Code:

function checkDatabaseFolderIsValid() {
global $DB_DIR, $DB_NAME;

// We have a db.inc.php file, so let's check if we can see the database folder.
if (!@opendir($DB_DIR . "/" . $DB_NAME)) {
echo "I was not able to open the database folder specified in your db.inc.php file. (".$DB_DIR . "/" . $DB_NAME.") Either the folder does not exist or it does not have enough read permissions.<p>You should fix this problem and then go through the installation wizard again.<p><b>Instructions To Restart The Installation Wizard:</b><p><b>1.</b> Open your <b>db.inc.php</b> file and delete the <b>contents</b>.<p><b>2.</b> Reload this page (click refresh in your browser) and the program will automatically detect that it needs to be reinstalled.";
exit;
}
@closedir($DB_DIR . "/" . $DB_NAME . "/");
}

(The $DB_DIR and $DB_NAME values are taken from the config.inc.php file in your /snippetmaster folder.)

I'm going to send you a test file to run on your server.  This will check to see what might be the problem...

You should have it in your inbox in a few minutes, and then I'm off to bed. 

[admin]

OK, I just sent you the test file.  Let me know what are the results. 

[Serra]

Resolution:

First, be aware that the default install of SnippetMaster is insecure.  The level of insecurity is very dependent on your web host.  The safer your web host is, the less danger that the insecurity of SnippetMaster poses.  However, if you are not well versed in Apache/Linux then you really don't know how insecure your system is. 

You should always use a web host that at a minimum uses mod_security, PHPSuExec, open_basedir restrictions, jailed shell (if shell is offered) and PHP 4.4.4 or better or a later version of PHP5.  If you are running your own server, you should have it hardened by a professional, such as configserver.com. 

The SnippetMaster documentation clearly states that the software installs itself in an insecure manor, but if you are like me, you used the autoinstall and didn't bother to read how to install it manually. The autoinstall works perfect, so why would I bother reading the manual install...


   The autoinstall creates an insecure system, in version SnippetMaster v2.2.2.  I hope this will be addressed in future versions.  The manual install also allows these insecure settings, but most users will not follow the instructions as it is clear it is insecure.

To secure the SnippetMaster installation, you should do the following:

in snippet install directory
chmod 644 db.inc.php
chmod 755 dnippet-db

/snippet-db
chmod the directories to 755 (Names will be different, should be one directory with a name that has a bunch of numbers and a letter or two in it.)

If you don't understand these instructions, we are changing the permissions from EVERYONE can WRITE to only the USER can WRITE to the folder and files.  The danger is that if someone can write to your folders, they can put programs or images into your directory and then access them online.  (which is a favorite tactic of hackers and bandwidth stealer)


This change will remove all 777 directories and the 777 file.  Keep in mind that if your system is not running PHPSuExec, this will likely cause SnippetMaster to stop working.  IMO, at that point, you need to change hosts or have your host install PHPSuExec.  (which can open one heck of a can of worms... so better to change hosts!  Converting from non-PHPSuExec to a PHPSuExec system can be difficult for novice users)

Once that the 777 folders and directories are removed, SnippetMaster works securely.   

However, I find it amazing that there is no discussion here of the insecurities of this software.   I spent 10 minutes search for people complaining about the 777 folder and saw nothing but users telling other uses to change their folders to 777 so that SnippetMaster would work properly.   That is really unacceptable.  Folders should not be set to 777 permissions.  Doing so allows hackers to exploit other security flaws in a system.  Granted, on the perfect system, a 777 folder offers only a small risk, but it is still a risk and once exploited can cause major problems. 

[admin]

I think it's important to clarify that it is not Snippetmaster that is insecure.  It is the the web server that could potentially be insecure.

And even then, it's still not insecure unless your website is hacked, and someone uses some exploit in some other software installed on your account to find and modify your "insecure" (world writable) files.  (Or in really bad cause of aweful server security setup, another user on your server is able to access files in your account...)

I do agree that all SnippetMaster users should find a web hosting provider that offers phpsuexec or other "secure" method of running CGI (PHP) software on the server.

If you need a good recommendation, please let me know.

[Serra]

Yes, SnippetMaster itself is totally secure (as far as I've seen).   I do believe the documentation should be updated to show that 777 permissions are not required on all systems and I believe the autoinstall program should be changed to not use 777 permissions when installing, if they are not needed on that system.

I also highly recommend using it, with the proper permissions in place.  It seems to work very well.

[gwmbox]

So what are your files set to for editing?

Thanks

[admin]

So what are your files set to for editing?

Thanks

It depends on how your web server is set up.  On some web servers, you can use permissions of "600".  And on some web servers, you must have permissions of "666" or "777".

You should talk to your web hosting provider and ask them what permissions are needed for a PHP program (Snippetmaster) to write to files in your account.

[Serra]

So what are your files set to for editing?

655 for general editing.  Any php file with 777 will not run on my server as it errors with a 500 error.  (Which is technically a 406 remapped to 500).

The issue here is that SnippetMaster should determine the correct permission level, either 655 or 777 depending on the server and set the proper security level when it installs. 

Of course this is a really old thread.  I haven't checked to see if things have changed.  I did install a few licenses last month without any issues, so things may be different now. 

In your specific case, you web host will need to tell you what the proper permission level is for your server.  However, I would suggest that any host using 777 permissions is bordering on being insecure.  Most secure hosts are no longer allowing 777 files and have converted over to SuPHP.

[admin]

So what are your files set to for editing?

The issue here is that SnippetMaster should determine the correct permission level, either 655 or 777 depending on the server and set the proper security level when it installs. 

No, Snippetmaster will never automatically change permissions of your website files.  I do want Snippetmaster to be easy-to-use, but I will not cross the line and make the installation so "easy" that it changes file permissions for any files in the website.  That is just one step too far into something I think should be the sole responsibility of the website owner.  (Changing permission of their files, only if desired, and not due to some automated software...)

I hope that makes sense.  I guess my feeling about this is that I would personally never trust *any* software to automatically change or manage permissions of my website files, and so I will not allow Snippetmaster to do this, even though it is easily technically possible.

If the website owner is not able to change permissions of the files they wish to be editable, then they can simply ask their web host for help.  (That's the web host's job to help the website owner.)  If the web host will not help, then the website owner should find a new host that actually cares about their customers and provides help when needed.

[Serra]

Actually, just to be clear.  I checked the last two installs, which were in the last month and all of the permissions are set to my system's normal settings, so I assume that any issues with permissions are a mute point now.

I guess my feeling about this is that I would personally never trust *any* software to automatically change or manage permissions of my website files, and so I will not allow Snippetmaster to do this, even though it is easily technically possible.

My fear is the opposite.  I fear that software that doesn't manage permissions, when it installs itself, is doing a disservice to users who are too uninitiated to understand the effects of permissions, as many users don't even know what permissions are or how they effect the operation and safety of their website.

Again, this is a mute point as Snippetmaster appears to be installing itself with the proper permissions without any changes.  I don't think this is anything to worry about at this point.  I'm not even sure why this tread was brought back from the dead.