CREATE USER

The CREATE USER command creates a new user account.

Note

Refer to Manage Organizations, Manage Organization Users, and Manage Database Users for more information about managing users and groups.

Syntax

CREATE USER [IF NOT EXISTS] user[@host]
[IDENTIFIED BY 'password']
[WITH {DEFAULT RESOURCE POOL = poolname} |
{FAILED_LOGIN_ATTEMPTS = integer PASSWORD_LOCK_TIME = integer} |
{DEFAULT RESOURCE POOL = poolname FAILED_LOGIN_ATTEMPTS = integer PASSWORD_LOCK_TIME = integer}]
[REQUIRE {SSL | X509 | SUBJECT | NONE}]
[ATTRIBUTE <valid json>]
[COMMENT <comment string>]

Arguments

  • user: Username of the SingleStore database user.

    • Non-JWT users: Maximum length of 32 characters.

    • JWT users: Maximum length of 320 characters.

  • host: The host that the user can connect from. For example, specifying localhost means the user account can be used only when connecting from the local host. If no host is explicitly specified, the % wildcard is used, which allows the user to connect from any host.

  • password: An optional database connection password for the user.

  • poolname: The default resource pool for the user.

FAILED_LOGIN_ATTEMPTS and PASSWORD_LOCK_TIME

FAILED_LOGIN_ATTEMPTS: Together with PASSWORD_LOCK_TIME, specifies the failed login attempt lockout behavior. FAILED_LOGIN_ATTEMPTS is the number of failed attempts allowed after which the account is locked out. For example, a value of 3 means that the account will be locked after three failed attempts. Default is 0, which means there is no restriction. When set to a value greater than or equal to 1, PASSWORD_LOCK_TIME must also be specified.

PASSWORD_LOCK_TIME: Together with FAILED_LOGIN_ATTEMPTS, specifies the failed login attempt lockout behavior. PASSWORD_LOCK_TIME is the number of seconds a locked out account must wait before reattempting to log in.

Note

You must set both FAILED_LOGIN_ATTEMPTS and PASSWORD_LOCK_TIME to enable the lockout feature.

To modify the FAILED_LOGIN_ATTEMPTS and PASSWORD_LOCK_TIME for a user, or to unlock a locked user, use ALTER USER.

If an account is locked either manually using the ALTER USER … ACCOUNT LOCK command or automatically as a result of exceeding the values specified for FAILED_LOGIN_ATTEMPTS and PASSWORD_LOCK_TIME arguments, then restarting the workspace removes the lock and returns the account’s status to ONLINE. The account lock needs to be explicitly re-applied after the workspace is back online and/or automated as part of the customer’s operational procedures. Users can confirm the lock state before and after a restart by viewing the ACCOUNT_STATUS column in the information_schema.USERS view.

REQUIRE

REQUIRE supports the following options:

  • REQUIRE SSL: Ensures that the user connects via SSL.

  • REQUIRE NONE: Specifies that SSL is not required for the connection.

  • REQUIRE X509: Enables mutual authentication between the client and SingleStore. The user can connect only if the client presents a valid TLS client certificate that is not expired and chains to the CA bundle configured on the server. Connections that do not provide a valid certificate are rejected. Example:

    CREATE USER 's2user'@'%' REQUIRE X509;
  • REQUIRE SUBJECT '<subject-dn-string>': In addition to extending REQUIRE X509, REQUIRE SUBJECT checks the subject in the client certificate provided during mTLS connection and enforces that the Subject DN in the client certificate must exactly match the configured value. This verifies both trust (via certificate chaining to the CA) and identity (via the Subject DN string). For example:

    CREATE USER 's2user'@'%' REQUIRE SUBJECT '/CN=s2user/O=example/C=US';

    When running CREATE USER or ALTER USER, specify the SUBJECT in OpenSSL “oneline” format. Separate fields, such as CN, O, C, ST, and L, with a /. To generate the Subject DN string in OpenSSL "oneline" format, run the following command:

    openssl x509 -in client-cert.pem -noout -subject -nameopt compat

    If the openssl output escapes characters inside a DN value, escape each backslash (\) in the output because the value is entered as a SQL string literal. For example, if the Subject contains \+, replace it with \\+ in the CREATE USER or ALTER USER statement. For example:

    CREATE USER 's2user'@'%' REQUIRE SUBJECT '/O=example/CN=Js3g\\+AF\\+/C=US';

    A Subject mismatch can return the same generic certificate verification error as CA-chain issues. To troubleshoot, first verify that the client certificate chains to the CA bundle configured on the server (REQUIRE X509), and then verify that the Subject DN in the certificate exactly matches the configured REQUIRE SUBJECT value.

ATTRIBUTE and COMMENT

Optional arguments used to provide additional information about a user. The values can be seen in the USERS information schema view. When both arguments are specified in the same statement, ATTRIBUTE must come first. For ATTRIBUTE, the value must be a valid JSON object.

Remarks

  • The CREATE USER command must be run by a user with administrative privileges on the database. Also, the new user does not have any privileges granted by default. Use GRANT to specify privileges for the new user.

  • Other CREATE USER command options aren’t applied in case the user exists and IF NOT EXISTS is specified; you must use the GRANT command to assign privileges or the ALTER USER command to change user properties.

  • The WITH keyword must be used with the following options and specified only once:

    • DEFAULT RESOURCE POOL = <poolname>

    • FAILED_LOGIN_ATTEMPTS = integer PASSWORD_LOCK_TIME = <integer>

    For example:

    • WITH DEFAULT RESOURCE POOL = pool1 FAILED_LOGIN_ATTEMPTS = 10 PASSWORD_LOCK_TIME = 20

    • WITH FAILED_LOGIN_ATTEMPTS = 10 PASSWORD_LOCK_TIME = 20

    • WITH DEFAULT RESOURCE POOL = pool1

  • This command causes implicit commits. Refer to COMMIT for more information.

  • In SingleStore Helios, you do not have the privileges to create your own resource pool. Raise a ticket with SingleStore Support to create it. Once the resource pool is created, you can assign it to users.

  • The CREATE USER command only applies to the current node unless the sync_permissions engine variable is set to ON.

  • The CREATE USER command holds a global lock on the workspace until the processing of the command is completed. Refer to Workspace Level Locks for more information.

  • Refer to the Permissions Matrix for the required permissions.

  • Refer to Configuring a Password Policy for information on how to configure a robust password policy.

Examples

  • The following example demonstrates how to add a new user and grant the SELECT privilege on all tables in the mydb database to the user:

    CREATE USER joe;
    GRANT SELECT ON mydb.* TO 'joe'@'%';
  • The following example demonstrates how to create a resource pool and assign it to a new user in addition to controlling the login attempts:

    CREATE RESOURCE POOL test_pool WITH QUERY_TIMEOUT = 20;
    CREATE USER user1 IDENTIFIED BY 'User123' WITH DEFAULT RESOURCE POOL = test_pool FAILED_LOGIN_ATTEMPTS = 3 PASSWORD_LOCK_TIME = 14400;
  • The following example demonstrates the use of the default_require_ssl variable and the REQUIRE option:

    CREATE USER `alice`@`%`; -- uses default_require_ssl var (off by default)
    CREATE USER `alice`@`%` REQUIRE NONE; -- does not require SSL
    CREATE USER `alice`@`%` REQUIRE SSL; -- requires SSL
  • The following examples demonstrate the use of ATTRIBUTE and COMMENT:

    CREATE USER 'user1'@'svchost-xxxx' ATTRIBUTE '{"phone": "1234567890"}';
    CREATE USER 'user1'@'svchost-xxxx' COMMENT 'Some information about user1';
  • The following example demonstrates how to retrieve the ATTRIBUTE and COMMENT values from the information_schema.USERS view:

    CREATE USER singlestore@svchost-xxxx ATTRIBUTE '{"a": 1, "b": 2}' COMMENT 'Some information about the SingleStore user.';
    SELECT USER, ATTRIBUTE, COMMENT from INFORMATION_SCHEMA.USERS WHERE user='singlestore';
    +-------------+---------------+----------------------------------------------+
    | USER        | ATTRIBUTE     | COMMENT                                      |
    +-------------+---------------+----------------------------------------------+
    | singlestore | {"a":1,"b":2} | Some information about the SingleStore user. |
    +-------------+---------------+----------------------------------------------+
    SELECT USER, ATTRIBUTE, COMMENT, ATTRIBUTE::a + ATTRIBUTE::b AS c FROM INFORMATION_SCHEMA.USERS WHERE user='singlestore';
    +-------------+---------------+----------------------------------------------+------+
    | USER        | ATTRIBUTE     | COMMENT                                      | c    |
    +-------------+---------------+----------------------------------------------+------+
    | singlestore | {"a":1,"b":2} | Some information about the SingleStore user. |    3 |
    +-------------+---------------+----------------------------------------------+------+

Last modified:

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined
  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined
  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
    cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
    --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
    --bundle undefined \
    --new-bundle-format -
    Verified OK

Try Out This Notebook to See What’s Possible in SingleStore

Get access to other groundbreaking datasets and engage with our community for expert advice.