Follow-up discovered while fixing the Key Management Admin privilege escalation (PR #329).
Severity: Low (least-privilege / correctness inconsistency)
Problem
spp_encryption/security/groups.xml links group_crypto_manager ("Full cryptographic administration including key generation and deletion. HIGHEST RISK") into spp_security.group_spp_admin — expressing the intent that OpenSPP admins hold a key-control role. But group_crypto_manager has no ACL rows on spp.encryption.key or spp.asymmetric.key (spp_key_management/security/ir.model.access.csv). So the role is non-functional at the data layer: the key-generation flow in spp_encryption/models/encryption_provider.py creates asymmetric keys in user context and therefore only ever worked for users who were also system administrators.
This surfaced during PR #329: a pure Key Management Admin previously reached spp_encryption provider configuration only via the covert group_key_admin → base.group_system → group_spp_admin → group_crypto_manager chain. With the escalation removed, that path is gone — exposing that the crypto-manager role never carried real key access on its own.
Decision needed
Either:
Pick one so intent and effect agree.
Related: #329.
Follow-up discovered while fixing the Key Management Admin privilege escalation (PR #329).
Severity: Low (least-privilege / correctness inconsistency)
Problem
spp_encryption/security/groups.xmllinksgroup_crypto_manager("Full cryptographic administration including key generation and deletion. HIGHEST RISK") intospp_security.group_spp_admin— expressing the intent that OpenSPP admins hold a key-control role. Butgroup_crypto_managerhas no ACL rows onspp.encryption.keyorspp.asymmetric.key(spp_key_management/security/ir.model.access.csv). So the role is non-functional at the data layer: the key-generation flow inspp_encryption/models/encryption_provider.pycreates asymmetric keys in user context and therefore only ever worked for users who were also system administrators.This surfaced during PR #329: a pure Key Management Admin previously reached
spp_encryptionprovider configuration only via the covertgroup_key_admin → base.group_system → group_spp_admin → group_crypto_managerchain. With the escalation removed, that path is gone — exposing that the crypto-manager role never carried real key access on its own.Decision needed
Either:
group_crypto_managerproper ACL rows on the key models (if OpenSPP admins are genuinely meant to manage crypto), orgroup_spp_adminlink (if key custody is meant to be separate from platform administration — consistent with PR security(key_management): stop Key Management Admin group from granting system admin #329's stance forgroup_key_admin).Pick one so intent and effect agree.
Related: #329.