Today one of our customers was having this error while executing curl from a cron job on his cPanel website: bash: /usr/bin/curl: Permission denied
The first thing to check was the curl binary, as it’s common to set it with permission 750 to disallow rouge scripts from execute curl or wget binaries.
[[email protected] ~]$ ls -alh /usr/bin/curl -rwxr-x--- 1 root root 118K May 10 2016 /usr/bin/curl [[email protected] ~]$
Set +x or 755 to /usr/bin/curl and it should be fixed
[[email protected]:~]chmod 755 /usr/bin/curl -v mode of `/usr/bin/curl' changed to 0755 (rwxr-xr-x) [[email protected]:~]
However, while the /usr/bin/curl binary had 755 permissions, while executing /usr/bin/curl as the cPanel user, it still showed the original permission denied error:
Let’s became the cpanel user to check dig a little bit more
[[email protected]:~] su johndoe
Execute curl from the user’s shell
[[email protected]]$ curl bash: /usr/bin/curl: Permission denied [[email protected]]$
Check the curl permissions again
[[email protected]]$ ls -alh /usr/bin/curl -rwxr-x--- 1 root root 118K May 10 2016 /usr/bin/curl [[email protected]]$
And there is a big difference between this curl result (cpanel user) and the root user executing curl, both are using different permissions:
root (755): -rwxr-xr-x 1 root root 118K May 10 2016 /usr/bin/curl user (750): -rwxr-x--- 1 root root 118K May 10 2016 /usr/bin/curl
How can the same binary report two different sets of permissions?
This is because this server is not a standalone cPanel server, but a cPanel server running CloudLinux.
One of the advantages of CloudLinux is CageFS. CageFS is a virtualized file system that locks each system user inside their own ‘cage’, allowing the users to execute their own system files, binaries, etc.
Having said that, the only thing left to check if CageFS was the reason for such strange behaviour.
Let’s disable CageFS temporary for that user:
[[email protected] ~]$ /usr/sbin/cagefsctl --disable johndoe [[email protected] ~]$ /usr/sbin/cagefsctl --list-disabled 1 disabled user(s) johndoe
And the curl binary is now working again. However, disabling such an important security feature wasn’t the root fix we were looking for.
Restore CageFS protection for the user
[[email protected] ~]$ /usr/sbin/cagefsctl --enable johndoe Updating users ...
And let’s take a quick look into how CloudLinux handles binaries
CageFS uses it’s own filesystem template, that it is located at /usr/share/cagefs-skeleton directory, this template will be used by each system user.
This template, includes many things, like curl binaries:
[[email protected] ~]$ ls -alh /usr/share/cagefs-skeleton/usr/bin/curl -rwxr-x--- 1 root root 118K May 10 2016 /usr/share/cagefs-skeleton/usr/bin/curl [[email protected] ~]$
There we have the root cause of the issue.
It seems when CloudLinux was installed, the curl binary already had 750 permissions, and it was included with that set of permissions on its own file system skeleton.
Now, in order to allow users to execute curl, wget or any other binary used in crons for example, you must change permissions for CloudLinux skeleton, and this will be automatically replicated over the cpanel user.
[[email protected] ~]$ chmod 755 /usr/share/cagefs-skeleton/usr/bin/curl -v mode of `/usr/share/cagefs-skeleton/usr/bin/curl' changed to 0755 (rwxr-xr-x)
Now finally, check if your user is now able to use curl:
[[email protected]:~] su johndoe [[email protected]]$ ls -alh /usr/bin/curl -rwxr-xr-x 1 root root 118K May 10 2016 /usr/bin/curl [[email protected]]$
The same method applies to wget or other common binaries you may need to use, and were restricted prior to install CloudLinux OS.
[[email protected] ~]$ chmod 755 /usr/share/cagefs-skeleton/usr/bin/wget -v mode of `/usr/share/cagefs-skeleton/usr/bin/wget' changed to 0755 (rwxr-xr-x)
That’s all, your bash: /usr/bin/curl: Permission denied error should be fixed if you followed this tutorial step by step.