When the KVS server starts for the first time with an empty database and no seed nodes configured, there is currently no mechanism to create an initial administrative user. This makes it impossible to interact with authentication-protected endpoints, like /kv.
Currently the api endpoints to create users and groups are not under the authentication midware. This is bad security practice.
Proposed Solution:
Introduce logic in the server initialization (NewServer function) to detect if the database is empty and if the seed_nodes configuration is empty. If both conditions are met, the server should:
Generate a default "root" user: Create a User entry with a server-generated UUID, a hashed nickname (e.g., "root"), and assign it to a default "admin" group (which should also be created if it doesn't exist).
Generate an API token for the root user: Create a APIToken for this root user with a set of predefined administrative scopes (e.g., "admin", "read", "write", "create", "delete").
Securely log the token: Print the generated root user's UUID and the full API token to the console (stdout/stderr) with a prominent warning that it should be saved securely and is only shown once.
Store the root user and token: Persist the created User and APIToken objects in BadgerDB.
This ensures that a new, uninitialized instance of the KVS server can be brought up with a functional administrative account, allowing immediate secure interaction with the API.
When the KVS server starts for the first time with an empty database and no seed nodes configured, there is currently no mechanism to create an initial administrative user. This makes it impossible to interact with authentication-protected endpoints, like /kv.
Currently the api endpoints to create users and groups are not under the authentication midware. This is bad security practice.
**Proposed Solution:**
Introduce logic in the server initialization (`NewServer` function) to detect if the database is empty and if the `seed_nodes` configuration is empty. If both conditions are met, the server should:
1. **Generate a default "root" user:** Create a `User` entry with a server-generated UUID, a hashed nickname (e.g., "root"), and assign it to a default "admin" group (which should also be created if it doesn't exist).
2. **Generate an API token for the root user:** Create a `APIToken` for this root user with a set of predefined administrative scopes (e.g., "admin", "read", "write", "create", "delete").
3. **Securely log the token:** Print the generated root user's UUID and the full API token to the console (stdout/stderr) with a prominent warning that it should be saved securely and is only shown once.
4. **Store the root user and token:** Persist the created `User` and `APIToken` objects in BadgerDB.
This ensures that a new, uninitialized instance of the KVS server can be brought up with a functional administrative account, allowing immediate secure interaction with the API.
**Relevant Code Sections:**
* `NewServer` function for initialization logic.
* `User`, `Group`, `APIToken` structs.
* `hashUserNickname`, `hashGroupName`, `hashToken` functions.
* `userStorageKey`, `groupStorageKey`, `tokenStorageKey` functions.
* `generateJWT`, `storeAPIToken` functions.
Added "HasUsers() (bool, error)" to auth/auth.go.
Added "Initial root account setup for empty DB with no seeds" to server/server.go. Diff from this in attachment.
Potential fix for this in https://git.rauhala.info/MrKalzu/kalzu-value-store.
Added "HasUsers() (bool, error)" to auth/auth.go.
Added "Initial root account setup for empty DB with no seeds" to server/server.go. Diff from this in attachment.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
When the KVS server starts for the first time with an empty database and no seed nodes configured, there is currently no mechanism to create an initial administrative user. This makes it impossible to interact with authentication-protected endpoints, like /kv.
Currently the api endpoints to create users and groups are not under the authentication midware. This is bad security practice.
Proposed Solution:
Introduce logic in the server initialization (
NewServerfunction) to detect if the database is empty and if theseed_nodesconfiguration is empty. If both conditions are met, the server should:Userentry with a server-generated UUID, a hashed nickname (e.g., "root"), and assign it to a default "admin" group (which should also be created if it doesn't exist).APITokenfor this root user with a set of predefined administrative scopes (e.g., "admin", "read", "write", "create", "delete").UserandAPITokenobjects in BadgerDB.This ensures that a new, uninitialized instance of the KVS server can be brought up with a functional administrative account, allowing immediate secure interaction with the API.
Relevant Code Sections:
NewServerfunction for initialization logic.User,Group,APITokenstructs.hashUserNickname,hashGroupName,hashTokenfunctions.userStorageKey,groupStorageKey,tokenStorageKeyfunctions.generateJWT,storeAPITokenfunctions.Potential fix for this in https://git.rauhala.info/MrKalzu/kalzu-value-store.
Added "HasUsers() (bool, error)" to auth/auth.go.
Added "Initial root account setup for empty DB with no seeds" to server/server.go. Diff from this in attachment.
This works! Perfect!