Security and Permissions Model
Relevant source files
The following files were used as context for generating this wiki page:
The Security and Permissions Model of ollacc focuses on the secure management of Ollama Cloud API credentials and the enforcement of local filesystem permissions to protect sensitive configuration data. The system operates as a thin wrapper that ensures user-specific API keys are stored with restricted access and transmitted securely to the Ollama Cloud API.
Primary security objectives include preventing unauthorized local access to authentication tokens, ensuring secure communication via HTTPS, and providing mechanisms for users to quickly purge sensitive data.
Sources: README.md:25-29, lib/auth.sh:1-3
Local Filesystem Permissions
ollacc enforces strict POSIX permissions during installation and configuration to ensure that sensitive data is only accessible by the owner. The application creates a dedicated directory structure within the user's home directory with restricted access.
Permission Hierarchy
The system applies specific modes to different components:
- Application Directory (
~/.ollacc): Set tochmod 700. Only the owner can read, write, or enter the directory. - Configuration File (
~/.ollacc/config): Set tochmod 600. Only the owner can read or write the file. This file contains the plain-textANTHROPIC_AUTH_TOKEN. - Launcher Executable: Set to
chmod 755, allowing execution by the owner and others (though the parent directory restriction typically limits this to the owner in practice).
Sources: install.sh:35-37, install.sh:58, lib/config.sh:42, README.md:46-47
Filesystem Structure Diagram
The following diagram illustrates the directory structure and the associated permission levels enforced by the installer.
Sources: install.sh:35-42, install.sh:58
Authentication Flow and Secret Management
The core of the security model is the management of the ANTHROPIC_AUTH_TOKEN, which serves as the Bearer token for requests to https://ollama.com.
Key Provisioning
On the first run, if no token is present, the system prompts the user to manually retrieve a key from the Ollama settings page. The key is read silently using read -r -s to prevent the token from being echoed to the terminal screen.
Sources: lib/auth.sh:22-51
Environment Variable Sanitization
To prevent conflicts with the Anthropic SDK and ensure the cloud endpoint is used correctly, the system explicitly clears certain environment variables while exporting others. A critical security and functional requirement is setting ANTHROPIC_API_KEY to an empty string to force the SDK to use the ANTHROPIC_AUTH_TOKEN (the Bearer token).
Sources: lib/auth.sh:56-60, README.md:104-109
Authentication Sequence
The following sequence diagram shows how the system handles authentication and credential persistence.
Sources: lib/auth.sh:15-51, lib/catalog.sh:28-36
Data Persistence and Sanitization
ollacc provides built-in mechanisms for users to manage and clear their security posture.
Configuration Sanitization
The config_set function uses a custom bash_escape helper to sanitize values before writing them to the configuration file. This prevents injection attacks where a malicious or malformed API key could execute arbitrary shell code when the config file is sourced.
Sources: lib/config.sh:10-27, lib/config.sh:34-36
Management Flags
Users can revoke local credentials using specific flags that trigger the config_unset function.
| Flag | Description | Implementation |
|---|---|---|
--key-clear | Purges the ANTHROPIC_AUTH_TOKEN from the config file. | Calls config_unset |
--model-clear | Purges the default model choice, reducing the footprint of user preferences. | Calls config_unset |
Sources: lib/flags.sh:12-28, lib/config.sh:56-66
Network Security
All external communications are routed through HTTPS to protect the integrity and confidentiality of data in transit.
- Endpoint Validation: The default
ANTHROPIC_BASE_URLis hardcoded tohttps://ollama.com. - Catalog Verification: The system verifies the user's authentication by attempting to fetch the authorized catalog from
https://ollama.com/api/tagsusing the stored Bearer token. If this fails with a 401 error, the system treats the key as invalid. - Scraping Security: Popular model rankings are scraped from
https://ollama.com/search?c=cloud. To ensure only authorized models are displayed, the system intersects the scraped list with the user's authenticated catalog.
Sources: lib/auth.sh:11, lib/catalog.sh:28-36, lib/catalog.sh:44-59, README.md:86-88
Conclusion
The ollacc security and permissions model relies on standard Unix-style access controls and secure environment variable handling. By isolating configuration in a restricted directory (chmod 700) and ensuring the sensitive API token is never shared with the local Ollama server, the system provides a secure, direct path to cloud-based LLM services.
Sources: README.md:15-20, install.sh:36-58