OpenEMR Directory Permissions

Management and Administration
1

fr4nkie wrote on Sunday, August 24, 2014:

In an effort to better understand OpenEMR, I’m attempting to install a test environment from source as opposed to using the apt package. Installation went smoothly, but I’m left curious about the difference in directory permissions between the two installation methods.

On my production server, which was installed with the apt package, the root user owns the entire openemr directory (maybe I ran package installer with sudo by mistake???). On my test server, which was installed manually from source, the default user owns the entire openemr directory.

Some google searching led me to outdated install instructions for version 3.1 which suggest changing ownership of a few select directories to the Apache user. So I have three options and I’m not sure which is the most effective/secure way to configure permissions.

Should I leave ownership to the default user and just change the specific file permissions noted on the wiki? Should I be changing ownership the Apache user to ensure the webserver has proper access to the directory? Or should I set ownership to root for security purposes?

Any insight would be appreciated!

2

yehster wrote on Sunday, August 24, 2014:

From a security standpoint. Minimum permissions for proper functionality are generally a good strategy.

Using 600 for all files and changing the owner to www-data is probably even more secure than any of your other options.

To understand why, you need to understand more about what the permissions really mean.

3

fr4nkie wrote on Sunday, August 24, 2014:

Hi Kevin,

Appreciate the feedback. To expand on what you’ve posted, I found some information on the Ubuntu forums which give a nice explanation for using the Apache user…

Basically, it’s just a user with stripped permissions so if someone managed to find a security hole in one of your web applications they wouldn’t be able to do much. Without a lower-user like www-data set, apache2 would run as root, which would be a Bad Thing® since it would be able to do anything and everything to your system.

I’ll request permission to edit the wiki and add that step to the Installation page.

4

yehster wrote on Sunday, August 24, 2014:

Security is not a “one size fits all” affair. That’s why Unix has differing file permission modes in the first place.

There are some disadvantages with using www-data and 600, such as if you are making frequent changes/customizations to .PHP files.

When managing sites, I’ve occasionally forgotten to set permissions properly on updated files and caused some inconvenience for users.

5

yehster wrote on Sunday, August 24, 2014:

Also, the purpose for changing to 600 as ROOT of these files

chmod 600 openemr/acl_setup.php 
chmod 600 openemr/acl_upgrade.php 
chmod 600 openemr/sl_convert.php 
chmod 600 openemr/setup.php 
chmod 600 openemr/sql_upgrade.php 
chmod 600 openemr/gacl/setup.php 
chmod 600 openemr/ippf_upgrade.php

is to make them INACCESSIBLE (disable them without deleting) after setup is complete.

6

fr4nkie wrote on Sunday, August 24, 2014:

I see what you mean about the disadvantages. I set the permissions as 600 under www-data, but now I can’t navigate the directory (without using “sudo -s”). Should have expected that.

Makes sense for a production server where such access will be minimal. I assume a test environment would probably work better with ownership going to the default user to prevent such headaches.

Would the following steps (run from openemr directory) be apprpriate to secure a production environment?

sudo chown -R www-data:www-data ./

sudo chmod -R a-rwx ./

sudo chmod -R u+rw ./

sudo chown root:root acl_setup.php acl_upgrade.php sl_convert.php setup.php sql_upgrade.php ippf_upgrade.php gacl/setup.php

sudo chmod 600 acl_setup.php acl_upgrade.php sl_convert.php setup.php sql_upgrade.php ippf_upgrade.php gacl/setup.php
7

fr4nkie wrote on Sunday, August 24, 2014:

After a little more tinkering, it would seem the last command I posted above is unnecessary since the permissions of user only read/write is already set with the third command and does not need to be reset after changing ownership.