User is_admin column resets to 0 on login

đź’¬ General Discussion
1

I’ve inherited support of an installation of SuiteCRM that in all honestly I just want to hit delete on. It’s bugged and broken, and I have no documentation on how it was configured.

I’m trying to set up a dev environment (there wasn’t one!) so that I can update, upgrade, debug and otherwise maintain the site, but I now can’t get in as admin.

I was set up as an admin, but I would log in and find that I didn’t have admin rights.

The first couple of times this happened, I had some success with going in via phpMyAdmin and setting is_admin to 1 in my record, but now every time I do that it instantly gets reset to 0 as soon as I attempt to log in.

Any ideas how to get round this?

We’re currently running version 7.11.22 (I’d like to update it, but until I’ve got a dev version to test with, there’s no way I can even attempt that).

2

This doesn’t sound like standard behavior to me, so I would look for any custom processes that are playing with user records. I can imagine someone not very gifted devising a “security” process that downgrades all admins except himself.

Look for cron jobs in Linux, custom scheduler jobs in SuiteCRM, logic hooks… or basically anything under custom directory that mentions “admin”.

3

or maybe even a database trigger?

1 Like
4

Checking on phpMyAdmin, no triggers on the users table, and in fact no triggers listed for the database.

We’ve got a 3rd-party login screen (“White label login for SuiteCRM” by SmackCoders), but I’m assured my manager was having this exact same problem before that was installed.

I’ve sshed in and /var/spool/cron is empty, and under etc there’s only a cron.daily folder, but this happens literally when I’m logging in. In fact, I’ve just observed even closer, and it occurs after the 2FA stage (we have passwords, then 2FA with Google Authenticator).
I set “is_admin” to 1 well over an hour ago, I refreshed phpMyAdmin before logging in – 1.
Refreshed after clicking login – 1.
Refreshed again after entering code and clicking login – 0.

Contents of cron.php:

<?php
 if (!defined('sugarEntry')) {
     define('sugarEntry', true);
 }

//change directories to where this file is located.
//this is to make sure it can find dce_config.php
chdir(dirname(__FILE__));

require_once('include/entryPoint.php');

$sapi_type = php_sapi_name();
if (substr($sapi_type, 0, 3) != 'cli') {
    sugar_die("cron.php is CLI only.");
}

if (!is_windows()) {
    require_once 'include/utils.php';
    $cronUser = getRunningUser();

    if ($cronUser == '') {
        $GLOBALS['log']->warning('cron.php: can\'t determine running user. No cron user checks will occur.');
    } elseif (array_key_exists('cron', $sugar_config) && array_key_exists('allowed_cron_users', $sugar_config['cron'])) {
        if (!in_array($cronUser, $sugar_config['cron']['allowed_cron_users'])) {
            $GLOBALS['log']->fatal("cron.php: running as $cronUser is not allowed in allowed_cron_users ".
                                   "in config.php. Exiting.");
            if ($cronUser == 'root') {
                // Additional advice so that people running as root aren't led to adding root as an allowed user:
                $GLOBALS['log']->fatal('cron.php: root\'s crontab should not be used for cron.php. ' .
                                       'Use your web server user\'s crontab instead.');
            }
            sugar_die('cron.php running with user that is not in allowed_cron_users in config.php');
        }
    } else {
        $GLOBALS['log']->warning('cron.php: missing expected allowed_cron_users entry in config.php. ' .
                                 'No cron user checks will occur.');
    }
}

if (empty($current_language)) {
    $current_language = $sugar_config['default_language'];
}

$app_list_strings = return_app_list_strings_language($current_language);
$app_strings = return_application_language($current_language);

global $current_user;
$current_user = BeanFactory::newBean('Users');
$current_user->getSystemUser();

$GLOBALS['log']->debug('--------------------------------------------> at cron.php <--------------------------------------------');
$cron_driver = !empty($sugar_config['cron_class'])?$sugar_config['cron_class']:'SugarCronJobs';
$GLOBALS['log']->debug("Using $cron_driver as CRON driver");

if (file_exists("custom/include/SugarQueue/$cron_driver.php")) {
    require_once "custom/include/SugarQueue/$cron_driver.php";
} else {
    require_once "include/SugarQueue/$cron_driver.php";
}

$jobq = new $cron_driver();
$jobq->runCycle();

$exit_on_cleanup = true;

sugar_cleanup(false);
// some jobs have annoying habit of calling sugar_cleanup(), and it can be called only once
// but job results can be written to DB after job is finished, so we have to disconnect here again
// just in case we couldn't call cleanup
if (class_exists('DBManagerFactory')) {
    $db = DBManagerFactory::getInstance();
    $db->disconnect();
}

// If we have a session left over, destroy it
if (session_id()) {
    session_destroy();
}

if ($exit_on_cleanup) {
    exit($jobq->runOk()?0:1);
}
5

Instead of looking at cron.php contents, have a look inside SuiteCRM, in Admin / Schedulers

That’s the list of stuff that cron.php will execute. You can enable and disable individual items temporarily to diagnose.

6

I just found this:

It seems to be a known issue, solved by updating the 2FA plugin.

7

Aha – thanks, my Google-fu is clearly getting weak. (Actually, my debugging. I kept forgetting to check exactly when the permissions flipped until talking to you guys.)

Anyway, I’ll get that done ASAP. Thanks again.

1 Like