Compiler Access Disabled
Hello,
What worries me a little is the compilers got reenabled for unprivileged users. I've always have that set to just the users in the wheel group. I can't really see BuycPanel enabling that when they were looking into my ErrorDocument issue. If they did, I'm sure they'd tell me before doing so and set it back afterwards. I can't see how or why they'd need a compiler. That happened around the same time, I hadn't noticed because the CSF didn't run it's daily scan yet. I don't see any signs of anyone compromising my system though. No opened ports (besides rpcbind) that wasn't there before, no new website files, nothing like that. Maybe it was just some fluke. Maybe cPanel updated and reset it on accident or something. I dunno.
-
Hello @Spork Schivago, The permissions on /usr/bin/gcc determine if compiler access is enabled or disabled: Compiler Access - Documentation - cPanel Documentation When compiler access is enabled (default), the /usr/bin/gcc file has the following permissions: -rwxr-xr-x root root When you disable compiler access, cPanel changes the permissions of the /usr/bin/gcc file to: -rwxr-x--- root compiler
It looks like CentOS recently published updates to the gcc package (I'm checking on CentOS 7 since that's what you are using on this particular system):# grep gcc /var/log/yum.log Dec 12 08:16:09 Updated: libgcc-4.8.5-11.el7.x86_64 Dec 12 08:18:15 Updated: gcc-4.8.5-11.el7.x86_64
Thus, the permissions were reverted back to the default permissions used on the package when it was updated through YUM. Did you update your system packages manually before the "/scripts/upcp" nightly run? If so, that would explain why it showed as disabled. The upcp process checks the status of the option from the /var/cpanel/compilerstatus.db file and determines if the permissions on /usr/bin/gcc should be updated. Thus, compiler access would have been disabled again upon the next upcp process if you updated your system packages manually. Thank you.0 -
Hi. I did not update my packages manually. I have them set to automatically update. However, I do remember seeing some error message about the cronupdate thing failing. I went in and tried executing the crontab entry manually, but this didn't do anything. It just sat there. I figured I probably wasn't meant to execute it manually. Anyway, the next night, the updates worked fine and there was a bunch of them. I might have ran yum upgrade or whatever after the crontab entry failed, I don't remember. If I did, there weren't any updates available. 0 -
However, I do remember seeing some error message about the cronupdate thing failing. I went in and tried executing the crontab entry manually, but this didn't do anything. It just sat there.
Could you verify which specific command you ran manually? Thanks!0 -
Yup. Give me a second here please. I tried executing: run-parts /etc/cron.daily
and I tried executing:/usr/sbin/yum-cron
The first command just seemed to hang, so I investigated and tried manually executing the various crontab entries. The first one I tried was the /usr/sbin/yum-cron. That just hung as well, and that's when I figured maybe I wasn't supposed to execute it manually. But that doesn't make any sense to me. I'm a super user and the crontab entries just run as if a user was typing the command manually. I haven't been getting a lot of sleep because of the baby and my brain doesn't work that well because of it. I'm now thinking that perhaps yum-cron was doing stuff, but because it's meant to run as a crontab entry, it doesn't display anything on the screen. So maybe it was updating and I canceled it. I'm testing my hypothesis but running it now, manually, but I'm just leaving it to see if it does anything after some time.0 -
Hello, It's likely the GCC package was updated when you ran the yum-cron command. This would explain the permission changes to /usr/bin/gcc. The following cPanel update would have corrected the permissions on the file. Thank you. 0
Please sign in to leave a comment.
Comments
5 comments