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.
[root@server.nixcp.com ~]$ ls -alh /usr/bin/curl -rwxr-x--- 1 root root 118K May 10 2016 /usr/bin/curl [root@server.nixcp.com ~]$
Set +x or 755 to /usr/bin/curl and it should be fixed
[root@server.nixcp.com:~]chmod 755 /usr/bin/curl -v mode of `/usr/bin/curl' changed to 0755 (rwxr-xr-x) [root@server.nixcp.com:~]
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
[root@server.nixcp.com:~] su johndoe
Execute curl from the user’s shell
[johndoe@server.nixcp.com]$ curl bash: /usr/bin/curl: Permission denied [johndoe@server.nixcp.com]$
Check the curl permissions again
[johndoe@server.nixcp.com]$ ls -alh /usr/bin/curl -rwxr-x--- 1 root root 118K May 10 2016 /usr/bin/curl [johndoe@server.nixcp.com]$
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:
[root@server.nixcp.com ~]$ /usr/sbin/cagefsctl --disable johndoe [root@server.nixcp.com ~]$ /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
[root@server.nixcp.com ~]$ /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:
[root@server.nixcp.com ~]$ 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 [root@server.nixcp.com ~]$
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.
[root@server.nixcp.com ~]$ 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:
[root@server.nixcp.com:~] su johndoe [johndoe@server.nixcp.com]$ ls -alh /usr/bin/curl -rwxr-xr-x 1 root root 118K May 10 2016 /usr/bin/curl [johndoe@server.nixcp.com]$
The same method applies to wget or other common binaries you may need to use, and were restricted prior to install CloudLinux OS.
[root@server.nixcp.com ~]$ 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)
your bash: /usr/bin/curl: Permission denied error should be fixed if you followed this tutorial step by step.
The End! should you have any inquiries, we encourage you to reach out to the Vercaa Support Center without hesitation.
