# Issue #3: Implement Autogenerated Root Account for Initial Setup **Status:** ✅ **COMPLETED** **Author:** MrKalzu **Created:** 2025-09-12 22:17:12 +03:00 **Repository:** https://git.rauhala.info/ryyst/kalzu-value-store/issues/3 ## Problem Statement The KVS server lacks a mechanism to create an initial administrative user when starting with an empty database and no seed nodes. This makes it impossible to interact with authentication-protected endpoints during initial setup. ## Current Challenge - Empty database + no seed nodes = no way to authenticate - No existing users means no way to create API tokens - Authentication-protected endpoints become inaccessible - Manual database seeding required for initial setup ## Proposed Solution ### 1. Detection Logic - Detect empty database condition - Verify no seed nodes are configured - Only trigger on initial startup with empty state ### 2. Root Account Generation Create a default "root" user with: - **Server-generated UUID** - **Hashed nickname** (e.g., "root") - **Assigned to default "admin" group** - **Full administrative privileges** ### 3. API Token Creation - Generate API token with administrative scopes - Include all necessary permissions for initial setup - Set reasonable expiration time ### 4. Secure Token Distribution - **Securely log the token to console** (one-time display) - **Persist user and token in BadgerDB** - **Clear token from memory after logging** ## Implementation Details ### Relevant Code Sections - `NewServer` function - Add initialization logic - `User`, `Group`, `APIToken` structs - Use existing data structures - Hashing and storage key functions - Leverage existing auth system ### Proposed Changes (from MrKalzu's comment) - **Added `HasUsers() (bool, error)`** to `auth/auth.go` - **Added "Initial root account setup for empty DB with no seeds"** to `server/server.go` - **Diff file attached** with implementation details ## Security Considerations - Token should be displayed only once during startup - Token should have reasonable expiration - Root account should be clearly identified in logs - Consider forcing password change on first use (future enhancement) ## Benefits - Enables zero-configuration initial setup - Provides secure bootstrap process - Eliminates manual database seeding - Supports automated deployment scenarios ## Dependencies This issue blocks **Issue #4** (securing administrative endpoints), as it provides the mechanism for initial administrative access.