Worrying Security issue with settings.dat.php

7 posts by 3 authors in: Forums > CMS Builder
Last Post: October 18, 2017   (RSS)

By zaba - September 20, 2017

I have noticed when editing "General Settings" in the cms, it changes the file permissions of settings.dat.php to 666, when it should be 644 (it is 644 before any changes are made). Is there a fix for this?

By Dave - October 4, 2017

Hi zaba, 

Thanks for posting.  Just researching this now.  I think this might be being caused by us calling umask(0) in the CMSB startup.  We had an issue years ago where the default permissions on some servers were setup such that created files weren't able to be viewed.  Can you try this test script to see what the permissions are on your server?  On our server we get 0644 on both.

<?php
  // _testperms.php - test what permissions files get created with on the server.

  // show all errors
  error_reporting(-1);
  ini_set('display_errors', '1');         //
  ini_set('display_startup_errors', '1'); //
  header("Content-type: text/plain");

  // server details
  print "Operating system: " .php_uname(). "\n";
  print "Web server: " .$_SERVER['SERVER_SOFTWARE']. "\n";
  print "PHP running as: " .get_current_user(). "\n";

  // make sure file doesn't exist
  $filepath    = __DIR__ . "/_testperms.dat";
  if (file_exists($filepath)) { unlink($filepath); }
  if (file_exists($filepath)) { die("Filepath already exists! $filepath"); }

  // create file and show permissions
  print "\numask is set to: " .sprintf('%o',umask()). "\n";
  print "Creating file with default permissions: \n";
  file_put_contents($filepath, "test");
  $permissions = substr(sprintf('%o', fileperms($filepath)), -4);
  print basename($filepath) . " $permissions\n";

  // set umask
  print "\nSetting umask to 0\n";
  umask(0);

  // create file and show permissions
  print "\numask is set to: " .sprintf('%o',umask()). "\n";
  print "Creating file with new permissions: \n";
  file_put_contents($filepath, "test");
  $permissions = substr(sprintf('%o', fileperms($filepath)), -4);
  print basename($filepath) . " $permissions\n";

  //
  print "\nDone!";
  
//eof

Let me know what the results are.

Dave Edis - Senior Developer
interactivetools.com

By zaba - October 5, 2017 - edited: October 5, 2017

Operating system: Linux lin241.XXXXXX.co.uk 3.2.83 #4 SMP Thu Oct 27 23:38:08 BST 2016 x86_64
Web server: Apache
PHP running as: XXXXXXX

umask is set to: 22
Creating file with default permissions: 
_testperms.dat 0644

Setting umask to 0

umask is set to: 0
Creating file with new permissions: 
_testperms.dat 0644

Done!

This is what happens:

Check settings.dat.php is set to 0644 (OK)

Go in to cmsb --> General settings, change nothing but press save.

Check settings.dat.php it is now set to 0666

Is there something in the save process that is causing this to happen??

Also DOES THE SAME TO ANY NEW IMAGES THAT ARE UPLOADED BY CMSB, IT SETS THEM TO 0666

By Deborah - October 5, 2017

I never noticed the 0666s before, but see the same for all installs and my test report matches Zaba's.

I have 0644s working now... here's what I did:

1) Changed the init.php umask to 0022 and now see 0644 permissions (that fixed the settings.dat permissions)

2) In upload_functions.php changed the $filepath 0666 to 0644 (that fixed the uploaded image permissions)

That all seems to work for me, but I defer to Interactive Tools for the qualified answer as mine may cause unexpected issues.

~ Deborah

By zaba - October 6, 2017

Thanks for posting Deborah. I'll wait for Dave to take a look, and see if this can act as a temporary solution which can then be rolled in to an incremental update (like you said).

By Dave - October 18, 2017

Hi zaba and deborah, 

Thanks for the feedback, I haven't fully researched this yet but I'll include a patch in the next release to allow you to set the umask and default permissions in the settings file so it's upgrade proof.

The issue we've had in the past is that some web servers run as the account username (say example.com runs as a system account called "examplecom") and some run as the default "nobody" user which has the least system permissions.  We've run into situations where Apache/PHP can create files (either as "nobody" or as the user account "examplecom") and then those same files can't be modified or removed via FTP because the FTP server is running as different user that isn't in the same group.  eg: webserver runs as nobody and ftp runs as examplecom or vice-versa.

Typically web hosting accounts should be configured so that they are isolated from each other, so even if you have world read/writable files in your folders other users on the same server can't access them (perhaps because your parent website folder is only readable by your user account.  Because even with 644 permissions, if someone had access to your folder they could still "read" /cmsb/data/settings.dat.php which contains your database username and password.  

So those are some of the considerations.  We've also seen servers with odd umasks that default created files to be unreadable by anyone.  In any case, I'll research it more before the next release and move those settings into settings.dat.php.  They might be undocumented to start but you'll at least have somewhere easy to override them. 

Hope that helps.  If you have any questions or suggestions feel free to let me know.

Dave Edis - Senior Developer
interactivetools.com