Prefer scoped restic service capabilities over a broadly executable privileged binary

Keep elevated backup reading power attached to the intended Linux service and reviewed execution path.

Source facts

Restic’s Linux examples describe CAP_DAC_READ_SEARCH as a way to bypass file-read and directory-search permission checks without running the whole backup process as root. They prefer ambient capabilities for the supervised process, including systemd service configuration. Granting that capability directly to an executable instead allows anyone who can execute it to use the elevated reading power, so execution must be restricted. File capabilities also disappear when that binary is replaced or self-updated.

Source: restic — Linux Capability Examples.

Applicability

This applies to the documented Linux restic capability approaches. It addresses read privilege and executable scope, not authorization to expose backups or grant the service arbitrary system-management capabilities.

DSE recommendation

DSE recommends reviewing the exact files the backup service needs to read and choosing the narrowest supervised privilege arrangement that meets that scope. Prefer service-bound capability configuration where appropriate, and treat the backup identity as sensitive even when its user ID is not root. Check repository write permissions separately. If file capabilities are unavoidable, restrict execution and include their verification in the binary-update procedure. Do not copy a capability-enabled executable into a generally accessible tools directory.

Verification

In a disposable service configuration, verify access to required test files and confirm ordinary unrelated users cannot gain the same elevated read path. Replace the test binary and inspect the relevant capability behavior. Retain service configuration and access results without copying private backup credentials into the review record.

Official reference

restic — Linux Capability Examples. Reviewed October 15, 2026.