SingleStore User Management

Configure the root Password

When SingleStore is installed, the root user is created on each SingleStore node. You are required to set a password when running sdb-admin create-node, but this can be set to a blank password for testing purposes. As a best practice, you should set a secure password for the root user.

Once your cluster is deployed, you can also change the password for the root user with the sdb-admin change-root-password command. This command configures the root password for a single SingleStore node. To configure the password on all nodes in a SingleStore cluster, run:

sdb-admin change-root-password --all --yes --password <secure_password>

Changing the root password is an online operation for both aggregators and leaves and you do not have to perform any additional operations; however, you must ensure your nodes are running before calling the change-root-password command.

While it is convenient to set the root password using a command-line argument, it is often recommended against this practice for security reasons. The command-line argument accepts passwords entered as plain text, which makes them vulnerable to being discovered in the list of processes running on the system during application runtime. The plain text passwords could also be saved and accessed in the history file if your command-line interpreter maintains a history. For example, in Bash, the command history including password inputs is logged at ~/.bash_history. In addition, the root password supplied as a command-line argument is displayed on-screen and is visible to anyone who is reading the user’s screen.

Some of the more secure, alternative methods to set SingleStore root password are as follows.

• Set the root password using the MEMSQL_PASSWORD environment variable. This option is best suited for automated applications.

• As of SingleStore Toolbox 1.6.4, Toolbox commands can solicit the root password interactively from users. The passwords entered in an interactive prompt are not displayed on-screen and are effectively secured from anyone reading the user’s screen. The interactive prompt is invoked if neither the --password flag nor the MEMSQL_PASSWORD environment variable has been used to set the root password.

Deleting Unnecessary Default Users

In MemSQL 6.0 and later, the only default user created on each SingleStore node during installation is the 'root'@'%' user, which should be configured as described in the previous section.

In MemSQL 5.8 and earlier, several default users are created on each SingleStore node during installation. SingleStore recommends deleting all of these default users except for the 'root'@'%' user.

To delete these users, use the DROP USER command. On each SingleStore node (including both aggregators and leaves), log in as the root user or another user with sufficient permissions, and run:

DROP USER ''@'localhost';
DROP USER ''@'127.0.0.1';
DROP USER 'root'@'localhost';
DROP USER 'dashboard'@'%';
DROP USER 'dashboard'@'localhost';

These additional default users are created in MemSQL installations of 5.8 and earlier, but not 6.0 and later. They are not changed during upgrade, so a SingleStore cluster installed on 5.8 or earlier and upgraded to 6.0 or later will still have these user accounts, unless you have deleted them.

Note that since user accounts are configured independently on each node, whenever you add a new SingleStore node, you should also delete any unnecessary default users on it.

Enable the Lockout Policy

To enable the lockout policy:

Set both FAILED_LOGIN_ATTEMPTS and PASSWORD_LOCK_TIME for the user or role. FAILED_LOGIN_ATTEMPTS is the number of failed attempts before the account is locked, for example: 4. PASSWORD_LOCK_TIME is the number of seconds a locked out account must wait before reattempting to log in.

Enable the lockout feature at 4 failed attempts, with a lockout time of 4 hours (14400 seconds) when creating a user:

CREATE USER user1 WITH FAILED_LOGIN_ATTEMPTS = 4 PASSWORD_LOCK_TIME = 14400;

Enabling the feature for a role:

CREATE ROLE general WITH FAILED_LOGIN_ATTEMPTS = 4 PASSWORD_LOCK_TIME = 14400;

If a user is associated with more than one role with different password lock times, the larger PASSWORD_LOCK_TIME value is applied.

If a user and a role the user is tied to have conflicting FAILED_LOGIN_ATTEMPTS settings, the lower value is applied.

Update Lockout Settings

If the PASSWORD_LOCK_TIME value is updated for a role or user, the new setting applies to currently locked accounts. For example, if a locked out user’s lockout time setting is 1 day, and PASSWORD_LOCK_TIME is then set to 4 hours, the new limit is enforced and the account will be unlocked 4 hours after it was locked. If a user’s lockout time setting is 4 hours, and the setting is increased to 1 day, the user will remain locked out for 1 day.

If the FAILED_LOGIN_ATTEMPTS setting for a locked out user is updated to be higher than the current setting, the user is unlocked. If the new setting is lower than the current number of failed login attempts, and also higher than the user’s current number of failed login attempts, the new setting is ignored until the user successfully logs in. The user is still subject to the original FAILED_LOGIN_ATTEMPTS setting.

Unlock a Locked Account

To unlock a locked account:

Use the ALTER USER command and specify ACCOUNT UNLOCK.

ALTER USER user ACCOUNT UNLOCK;

If sync permissions is not enabled, ACCOUNT UNLOCK should be issued on the aggregator where the user is to be unlocked.

If sync_permissions is enabled, ACCOUNT UNLOCK should be issued on the Master Aggregator since all user modifications will have to come from the Master. This will unlock the account across the cluster.