Expand description
Linux kernel keyring backend for secretx.
§Integration test status
Unit tests (URI parsing, error mapping) pass without credentials.
The integration test (SECRETX_KEYRING_INTEGRATION_TESTS=1) uses the Linux
kernel keyring directly (no daemon required). Run with:
SECRETX_KEYRING_INTEGRATION_TESTS=1 cargo test -p secretx-keyringOn Linux, secrets are stored via the kernel
persistent keyring,
which survives across logout/login sessions for a configurable window
(default: a few days, set by /proc/sys/kernel/keys/persistent_keyring_expiry).
Secrets do not survive reboots.
See keyutils(7)
for the kernel keyutils subsystem overview.
Persistent keyring probe: get and put probe keyctl_get_persistent
before each operation. If the kernel does not support
CONFIG_PERSISTENT_KEYRINGS (e.g. some containers, restricted namespaces,
or hardened kernels), SecretError::Unavailable is returned rather than
silently falling back to the session keyring (which expires when the process
exits).
Integration-tested 2026-04-28: Linux headless (kernel persistent keyring, no daemon).
URI: secretx:keyring:<service>/<account>
use secretx_keyring::KeyringBackend;
use secretx_core::{SecretStore, SecretValue, WritableSecretStore};
// Read
let store = KeyringBackend::from_uri("secretx:keyring:my-app/api-key")?;
let value = store.get().await?;
// Write (requires WritableSecretStore in scope)
store.put(SecretValue::new(b"new-secret".to_vec())).await?;Structs§
- Keyring
Backend - Backend that reads and writes secrets via the Linux kernel keyring.