Can't authenticate to atticd on second run

[vonjackets]

Let me start of by saying, this is a pretty cool project I discovered fumbling around with Nix, the "out of the box" experience was what hooked me, but when I started playing around with deploying as a cache server for my CI / CD builds, I quickly ran into trouble. I'm currently working on a solution now reflected in #210 , but here's what I've noticed.

Background

The Attic server (atticd) and its administrative tool (atticadm) rely on stateless authentication mechanisms using RS256 JWT tokens. Though atticd can be launched in different "modes", I find it more accurate to think of these as "tasks" we assign to an instance of the daemon.

Monolithic Mode - when not provided a config in any of the expected places, the server will run an "out of the box experience" function that checks for an existing configuration, if no config is found, the server generates a local sqllite db, root token, and a configuration toml file. However, if a configuration is found, it exits before doing anything meaningful. Leaving users unable to authenticate, this logic is also applied to atticadm as it runs through the same flow when loading a configuration, so even though it will create tokens based on the config found, they won't authenticate with the server!

---

Problem Analysis

Panic when running in other modes without configuration

I also noticed this when playing with it, trying to run in api-server mode with no config panicked every time.

• Scenario: Running atticd --api-server without a pre-existing configuration file causes a panic.
• Root Cause: The run_oobe function, responsible for generating default configurations and tokens, is bypassed when the server is executed in API Server mode, leaving the server in an undefined state.
• Impact: This prevents the server from starting properly in a default configuration, blocking administrators from easily deploying the API Server.

---

Missing Root Token in Monolithic Mode with Pre-Existing Configuration

• Scenario: When the server is run in Monolithic Mode with a configuration file that includes an RS256 key, the run_oobe function is skipped. This prevents a root token from being generated.
• Root Cause: The logic incorrectly assumes that the presence of a configuration file implies a fully initialized server, bypassing critical token generation steps.
• Impact:
  1. Authentication Failure: Administrators cannot authenticate to the server because no root token is created.
  2. Operational Failure: atticadm generates "do-nothing" tokens, effectively rendering it non-functional.
  3. Deployment Inconsistency: The behavior creates discrepancies between first-run and subsequent runs of the server.

---

Proposed Resolutions

To address these issues, the following changes can be implemented

1. Unified Initialization Workflow

• The run_oobe function was removed, the critical setup steps to run db migrations and create a root token should run regardless of the server mode when the --init flag is passed.
  Specifically:

  • For Non-monolithic modes: The server now creates a root token when provided a configuration and given the --init flag, if no config is provided, it will fail.
  • For Monolithic Mode: The server checks for an existing configuration,if one is found and the --init flag is passed, a new root token is generated from the present secret key, and database migrations are ran to ensure it is up to date.

  If a config is not found, the run_oobe workflow is performed - the local sqllite database, a configuration.toml, and a root token are created - regardless of whether the server was told to init (to preserve oobe)

2. Enhanced Error Handling

• To prevent panics in API Server mode, default configurations are now created on-the-fly if none are present. This ensures that the server can start in a safe and consistent state.
• Additional output should be given and the server processes should exit more gracefully when a configuration fails to be found.
• Gracefully handling other failures to parse the server configuration toml should also occur, the server can validate the configuration as a dry-run before using it with helpful output

---

Benefits of the Changes

1. Improved Reliability: The server no longer panics when run in API Server mode without a configuration.
2. Consistent Token Management: Administrators can authenticate to the server in all deployment scenarios, ensuring operational continuity.
3. Streamlined Deployment: First-time remains relatively seamless, with automatic configuration and token generation.
4. Backward Compatibility: Existing configurations with RS256 keys remain valid, while the server dynamically handles token creation as needed.

---