From 2698ef081fab663e17726685830ecaacc9f5784d Mon Sep 17 00:00:00 2001 From: Mario Ruci Date: Mon, 10 Aug 2026 16:01:04 +0200 Subject: [PATCH] docs(users): document that system-level actions share one permission SystemUpgrade, SetDisasterRecovery and SystemRestore are presented as separate actions in the wallet and the policy editor, but all three resolve to a single permission. Policies are matched by that shared key and OR-combined, so the least restrictive policy on any of the three governs all of them, and SystemRestore cannot be scoped at all. Delegating disaster recovery configuration is also terminal on its own, since it sets which group is the recovery committee and its quorum, so a group able to approve it can appoint itself and recover the station with code of its choosing. Document both so operators can size the delegation correctly. Co-Authored-By: Claude Opus 5 --- docs/src/content/docs/users/permissions-policies.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/docs/src/content/docs/users/permissions-policies.md b/docs/src/content/docs/users/permissions-policies.md index db2d8dea0..f9b9f9220 100644 --- a/docs/src/content/docs/users/permissions-policies.md +++ b/docs/src/content/docs/users/permissions-policies.md @@ -116,6 +116,19 @@ Approval policies can be based on the following rule types: 4. Configure any additional parameters, such as quorum size or percentage. 5. Save the policy to activate it. +## **System-Level Actions Share One Permission** + +**System upgrade**, **Configure disaster recovery**, and **System restore** are listed as separate actions, but they are governed by a single underlying permission. A policy configured for any one of them applies to all three. Because matching policies are combined with OR, the **least restrictive** policy on any of the three decides all of them. + +This matters when delegating: + +- Granting a group approval authority over **Configure disaster recovery** also gives them approval authority over **System upgrade**, which installs station code. +- Configuring disaster recovery sets *which group is the recovery committee, and its quorum*. A group that can approve that change can appoint itself as the committee and then recover the station using code of its choosing. It is therefore equivalent in power to a station upgrade in its own right, independently of the shared permission. +- Adding a **more** restrictive policy to one of the three does not tighten the others. The least restrictive matching policy still applies. +- **System restore** cannot be configured on its own; it is always governed by whichever policy covers the shared permission. + +Treat all three as a single, highest-privilege capability, and delegate them only to the group you would trust to replace the station's code outright. + ## **Best Practices for Approval Policies** - **Use Predefined policies for Consistency:** Define approval rules for common approval scenarios to reduce errors.