Child pages
  • Discourage usage of "root" user in the Admin Console [5.2.2-B2]
Skip to end of metadata
Go to start of metadata

The "root" user is only user account available after performing In-Portal installation. This user is special, because:

  • it can't be deleted or disabled
  • no permissions are checked for this user

Latter fact allows to perform login to Admin Console even if website access permissions were changed to the level, that no other Administrator isn't able to do so.

This is all nice and shiny, but using "root" account by default isn't the safest way to work with In-Portal. Instead the recommended approach is (but we never wrote about this anywhere) to create an Administrator account and use it instead of "root" user.

Solution

Add a banner in the Administrative Console (e.g. top frame or above every page in main frame) that:

  • is shown only when "root" user is logged-in
  • has text similar to this:

    You're logged-in using "root" user account, which poses a security risk if used unwisely.
    It's recommended to create an Administrator account at [User Management > Administrators] section and use that to access Administrative Console from now on.

Related Discussions

Related Tasks

7 Comments

  1. Maybe we should think about "why we need 'root' user after all" instead. For example WordPress installation wizard asks to enter both "username" and "password" for Administrator account that will be automatically created and later used at least by user, who installed WordPress to access Admin Console.

    Then we can set some random password to "root" user because nobody really should use it and let user, who installed In-Portal create user accounts for each Administrator.

  2. Dmitry Andrejev [Intechnic], please post an idea that we've discussed on the Huddle.

    1. Alex it's not clear what I need to post here since you already posted a plan for replacement solution

      1. Your original solution. Which is allowing to somehow disable "root" user account.

        1. Alex - okay, my original suggestion / idea was to keep ROOT in the system, but being able to disable ROOT user via debug.php or config.php and being able to turn it ON/OFF on demand.

          1. Here are the problems I've encountered while trying to imagine workflows with "root" user disabled, that are addressed my improved solution:

            1. you need to enable "root" user and then disable it again to:
              1. perform install/upgrade
              2. add new modules after In-Portal is installed
            2. user can disable "root" user while being logged-in as "root" user and/or being only administrator on website
            3. after initial install you need to go and create administrator and then use it do disable root user
  3. Replacement solution which is evolved and detailed solution of what was discussed with Dmitry Andrejev [Intechnic] before:

    Part 1 (access installation wizard by permission)

    1. add "in-portal:mod_status.advanced:install" permission (the "Configuration > Website > Modules" section)
    2. during installation/upgrade add "admin.install" group with "ADMIN.LOGIN" and "in-portal:mod_status.advanced:install" permissions
    3. in the "ModulesEventHandler::OnAfterListQuery" and "ModulesTagProcessor::_hasPrivileges" check if user has "in-portal:mod_status.advanced:install" permission rather than checking for user to be "root"
    4. add "kInstallToolkit::hasAccess" method, that will check if current user has "in-portal:mod_status.advanced:install" permission
    5. use "kInstallToolkit::hasAccess" method in "install.php" file of each module instead of checking for "root" user specifically

    Part 2 (disabling "root" account)

    1. add "RootUserEnabled" system setting (radio button with Yes/No values) above "RootPass" system setting
      1. "No" for clean install
      2. "Yes" for upgrade
    2. when "root" (or "super-root") user is attempting to set "RootUserEnabled" system setting to "No", then trigger set validation error with "Only administrators are allowed to disable "root" user account" message
    3. in the "core/install/install_data.sql" change value of "RootPass" system setting to be hash of empty password
    4. in "UserHelper::loginUser" method:
      1. if "root" or "super-root" is used as username, then block login attempt when "RootUserEnabled" system setting is set to "No"
      2. ensure, that "root" (or "super-root") user won't be able to login with an empty password

    Part 3 (create admin user during install)

    1. change "UserHelper::checkLoginPermission" method to additionally check "in-portal:mod_status.advanced:install" permission, when it's an installation (the "IS_INSTALL" constant is defined)
    2. in the "kInstallator::InitStep" method for "install_setup" step:
      1. remove code that looks up username/password on Intechnic servers (we no longer issue licenses from there)
      2. always use code, that was used for "root" login explicitly to login any user (see above for extra permission check)
    3. change "/core/install/step_templates/root_password.tpl" template like so:
      1. add "Admin Username" field (required, on top)
      2. add "Admin Email" field (required, after username)
      3. rename "Root Password" field into "Admin Password"
      4. rename "Confirm Root Password" field into "Confirm Admin Password"
    4. add "kInstallator::prepareAdminUser" method, that will:
      1. create dummy user object
      2. set all fields from "root_password" step form form into it
      3. return user object
    5. in "kInstallator::PerformValidation" method for "root_password" step:
      1. call "kInstallator::prepareAdminUser" method to obtain user object
      2. call "kDBItem::Validate" method on it
      3. if validation failed set 1st validation error (there can be several) in "!la_fld_FieldName!: error message" format as "$this->errorMessage" for this step
    6. update "/core/install/steps_db.xml" file, where for "root_password" step:
      1. change "title" to "Create Admin Account"
      2. change "help_title" to "Create Administrator Account"
      3. change step description to something that means this:
        1. this user is used to access Admin Console from now on
        2. you can create more administrators later if needed
        3. only this used can be used to access installation wizard later (e.g. for upgrading)
    7. update "/core/install/steps_db.xml" file, where for "install_setup" step:
      1. change "... the left you must enter your admin Root password." into "... the left you must enter Administrator username and password, that was created during initial installation process."
      2. remove "(Use Username 'root' if using your root password)" password hint
    8. in the "u:OnBeforeItemDelete" prevent attempt to delete user, when it has "in-portal:mod_status.advanced:install" permission
    9. in "kInstallator::Run" method for "root_password" step:
      1. don't set "RootPass" system setting
      2. call "kInstallator::prepareAdminUser" method to obtain user object
      3. call "kDBItem::Create" method on that user object (the fields should already be valid)
      4. add created user to "admin.install" group
      5. in "UserHelper::loginUser" call made later in this method use username/password of that user to perform a login