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 privileges information. To connect to a cluster, an user will use it 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 a quasardb secured cluster in 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 an unique UID. Internally, the system will use the UID to identify the user, not the username. The UID must be unique accross 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 an UID of 1. It is however up to the administrator to follow that convention or not.

Privileges¶

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

disabled: Whether the user is allowed to login into the system (true) or not (false).
superuser: Whether the user is a superuser (true) or not (false).
default_privileges: The combination of default privileges flags that will be used, if no explicit privilege for the user is available for the given object.

The available privileges 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 an user, by default, to select, insert, and set_transaction the default_privileges values 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 that 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 an user named “alice”, with an UID of 100, select as default privileges, to the user files contained 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 an user named “alice”, with an UID of 100, select as default privileges, to the user files contained 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 an user “alice”, with an UID of 100, select as default privileges, and output everything on the console:

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

To add a superuser “root”, to the user files contained 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