User Permissions problem in CentOS 7: “Permission denied”

Question

I thought that I knew how to set up permissions in Linux. I apparently don't.

I have a user called "web3". This user was automatically created by ISPConfig (A server management application like CPannel).

I also have an application that I installed on the server called "Drush". I installed "Drush" while logged in as root. This application is located at:

/root/.composer/vendor/drush/drush/drush

This file and it's containing folder have the following permissions:

-rwxr-xr-x 1 root root
drwxr-xr-x 9 root root

Since the file allows read and execute permissions to everyone, how come every time I login as the "web3" user and try to run the aforementioned application I get the following error message:

/root/.composer/vendor/drush/drush/drush: Permission denied

I have faced this problem before but I resorted to giving sudo full root permissions to the user I was having problems with. On a local development environment, this is not a big deal. I am managing my own Dedicated Server now and this sledgehammer solution will not do.

What am I doing wrong?

I'd appreciate any help!

Answer 1

/root/ is root's home directory. The permissions on /root/ are hopefully 700, preventing anyone but root from traversing the entire directory tree below it.

You're being prevented from running the binary as a non-root user by permissions further up the directory tree.

Installing anything into /root/ is unusual, you would normally install executable code to be used by multiple users into /opt/ or another directory.

So those are the two main things that are 'wrong'. You need to find a better location to install the code, and to ensure the full path is accessible to the users you want to use it.

Lastly, as others have pointing out, while you often need to be root to complete an install, the resulting files should only be owned by root if absolutely necessary. In many cases, specific users are created (such as the www-data user, or an oracle user) which limits exposure if the code is compromised. I don't know your application, but it might be worth either installing it as the web3 user or installing it as root, but changing the permissions later to a non-privileged user created specifically for the task.

You should resist the urge to open up the permissions on /root/ to fix the issue, and sudo is a sticking plaster over the problem. The problem is that you should not install executable code into root's home directory.

Answer 2

Just checking the permissions of the containing folder will not be enough: you'll need to check the permissions of all the higher-level folders, up to the root directory. For example, like this:

# ls -ld /root/.composer/vendor/drush/drush/drush \
  /root/.composer/vendor/drush/drush \
  /root/.composer/vendor/drush \
  /root/.composer/vendor \
  /root/.composer \
  /root \
  /

You may find that the /root directory has permissions 700 (or drwx------), and that is blocking the web3 user from proceeding any further on that path. It is not a good idea to let other users access the home directory of the root user, although you technically could give it permissions 711 (drwx--x--x) if you consider it absolutely necessary.

But it is possible that this won't help you either...

You're using CentOS 7, which has SELinux enabled by default.

RHEL/CentOS has a default SELinux configuration that usually has a pretty negligible effect on regular user accounts, but it can place some strict limits on system services - like a web server, for example.

Under SELinux, it is possible to restrict a process and all of its descendants from certain actions - independently from traditional Unix-style user/group/permissions system. Those restrictions can be configured to automatically "latch on" when certain binaries are executed, for certain system users, and on a multitude of other conditions.

One of the default SELinux restrictions for a webserver is that access to anything outside specifically enabled directories like /var/www is blocked, unless specifically enabled using a SELinux boolean, a kind of switchable option in SELinux ruleset. I think this might be another thing stopping the web3 user from accessing the Drush application.

If you want a web server (or any of its descendants, like a PHP interpreter) to access any content that is not under /var/www and is created by other users, you'll need to run this command:

# setsebool -P httpd_read_user_content 1

On RHEL/CentOS, each system service has an additional man page, named like <service name>_selinux, that contains information on SELinux restrictions and booleans for that specific service. Those man pages come in a RPM package named selinux-policy-doc: here's more information about that package. If you're using a system with SELinux enabled, you really should read those man pages for all the services you're planning to run: they make dealing with SELinux just so much easier.

Of course, you may find on the internet a lot of suggestions on how to disable SELinux, but if you are planning to run a secure server, that might not be the best option.