The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

SOLVED Compiler Access Disabled

Discussion in 'General Discussion' started by Spork Schivago, Dec 14, 2016.

  1. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    462
    Likes Received:
    52
    Trophy Points:
    28
    Location:
    corning, ny
    cPanel Access Level:
    Root Administrator
    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.
     
    #1 Spork Schivago, Dec 14, 2016
    Last edited by a moderator: Dec 15, 2016
  2. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    37,064
    Likes Received:
    1,287
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Hello @Spork Schivago,

    The permissions on /usr/bin/gcc determine if compiler access is enabled or disabled:

    Compiler Access - Documentation - cPanel Documentation

    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):

    Code:
    # 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.
     
  3. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    462
    Likes Received:
    52
    Trophy Points:
    28
    Location:
    corning, ny
    cPanel Access Level:
    Root Administrator
    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.
     
  4. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    37,064
    Likes Received:
    1,287
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Could you verify which specific command you ran manually?

    Thanks!
     
  5. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    462
    Likes Received:
    52
    Trophy Points:
    28
    Location:
    corning, ny
    cPanel Access Level:
    Root Administrator
    Yup. Give me a second here please.

    I tried executing:
    Code:
    run-parts /etc/cron.daily
    
    and I tried executing:
    Code:
    /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.
     
  6. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    37,064
    Likes Received:
    1,287
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    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.
     
Loading...

Share This Page