quasardb user adder#

Introduction#

The server keeps a user list in a JSON format, which contains the list of authorized users.

Example:

{
    "users": [
        {
            "uid": 1,
            "username": "root",
            "disabled": false,
            "superuser": true,
            "default_privileges": 0,
            "public_key": "PoCzwwX8Gdq7Mzz/RG6rH6vRhX84/RupFvVOjXauOEBM="
        },
        {
            "uid": 10,
            "username": "quant",
            "disabled": false,
            "superuser": false,
            "default_privileges": 30,
            "public_key": "Pr0vI41GyHTjJX5ufc+ga0KDdzEfd5OZ6J6F5V42AHj4="
        },
        {
            "uid": 20,
            "username": "pnl",
            "disabled": false,
            "superuser": false,
            "default_privileges": 2,
            "public_key": "PIsIvNyuiaNCQspxpz6LCDdUpP3AbKlFa3iOsj1QKgBQ="
        }
    ]
}

The user list contains the public key as well as privilege information. To connect to a cluster, a user will use their name and private key.

The private key must only be known to the administrator and the authorized user.

The quasardb user adder tool enables you to authorize users to access a secured quasardb cluster by generating the required public/private key pair and updating the users list file.

Reserved username#

The username “>[HAL_9000]<” is reserved by the cluster for internal authentication and cannot be used.

User ID#

Each user is identified by a unique UID. Internally, the system will use the UID to identify the user, not the username. The UID must be unique across all users. The UID may not be 0. The value of the UID does not have any influence on the privileges of the user.

By convention, the original superuser has a UID of 1. It is however up to the administrator to follow that convention or not.

Privileges#

In addition to the authentication token, the following information is specified for each user:

  • disabled: Whether the user is prevented from logging in to the system (true) or allowed to log in (false).

  • superuser: Whether the user is a superuser (true) or not (false).

  • default_privileges: The combination of default privilege flags that will be used, if no explicit privilege for the user is available for the given object.

The available privilege flags for users are:

  • denied: 1 - The absence of privileges. When this flag is present, all other privileges will be ignored.

  • select: 2 - The right to select (read) information from an object.

  • insert: 4 - The right to insert (add additional) information into an object.

  • update: 8 - The right to update existing value(s) of an object.

  • delete: 16 - The right to delete value(s) inside an object.

  • index: 32 - The right to create or modify indexes of tables.

  • alter: 64 - The right to alter the properties of an object.

  • create: 128 - The right to create an object.

  • drop: 256 - The right to delete an object.

  • grant: 512 - The right to manage rights of an object.

  • user_manage: 1024 - The right to manage users inside the system.

  • system: 2048 - The right to execute cluster-wide commands such as purging the caches.

  • set_acl: 4096 - The right to modify access control to entries.

  • get_acl: 8192 - The right to read access control list of entries.

  • set_transaction: 16384 - The right to commit or rollback a transaction.

To allow a user, by default, to select, insert, and set_transaction the default_privileges value should thus be 16390 (2 + 4 + 16384).

When a user is a superuser, all permissions and privileges explicitly specified are ignored. It is recommended to keep the superuser count to the strict minimum, ideally one, and to administrate with a user with enough privileges to perform the day-to-day administrative tasks.

The default privileges are ignored for every entry with explicit privileges for the given user.

Note

Any user with write access to the system should be given set_transaction privileges. Without those privileges, they may not be able to complete multi-entry operations, as they will not be able to commit the transaction.

Usage#

The user adder tool can write the information to files or on the standard output. If the provided output file for the public key already exists, the new user will be added to the existing file.

To add a user named “alice”, with a UID of 100 and select as the default privilege, to the user list in /etc/qdbd/users.cfg and store the private key in the local file alice_private.key:

qdb_user_add -u alice --uid=100 --privileges=2 -p /etc/qdbd/users.cfg -s alice_private.key

To add a user named “alice”, with a UID of 100 and select as the default privilege, to the user list in /etc/qdbd/users.cfg and output the private key to the console:

qdb_user_add -u alice --uid=100 --privileges=2 -p /etc/qdbd/users.cfg -s -

To generate a key pair for a user “alice”, with a UID of 100 and select as the default privilege, and output everything to the console:

qdb_user_add -u alice --uid=100 --privileges=2 -p - -s -

To add a superuser “root”, to the user list in /etc/qdbd/users.cfg and store the private key in the local file root_private.key:

qdb_user_add -u root --uid=1 --superuser=on -p /etc/qdbd/users.cfg -s root_private.key