Red Hat Bugzilla – Bug 1253459
ipa vault-add creates service vault with non-existent service
Last modified: 2016-02-15 12:53:15 EST
Description of problem: [root@master ~]# ipa vault-add vname --service=service_dne ------------------- Added vault "vname" ------------------- Vault name: vname Type: standard Owner users: admin [root@master ~]# ipa vault-show vname ipa: ERROR: vname: vault not found [root@master ~]# ipa vault-show vname --service=service_dne Vault name: vname Type: standard Owner users: admin Version-Release number of selected component (if applicable): ipa-server-4.2.0-4.el7.x86_64 How reproducible: always Steps to Reproduce: 1. ipa-server-install 2. ipa-kra-install 3. kinit admin 4. ipa vault-add vname --service=service_dne Actual results: adds vault Expected results: should not add vault Additional info:
Upstream ticket: https://fedorahosted.org/freeipa/ticket/5215
Was discussed offline and was decided that creating a vault for non-existent user/service is a valid use-case.
Reopening this bug for either more detailed clarification of why adding a vault for a non-existent service is valid or to get this resolved. IMHO, we should not add a service vault until after the service is added. Thanks, Scott
The reason is consistency with delete operation. Vault is not deleted when user is deleted to preserve secrets. So the state can be achieved even if it is not permitted. Maybe the add operation can print a warning that the user|service doesn't exist, e.g. to solve "typo" mistakes.
A warning on add would be good but, is it possible instead to add a warning on user-del? To me it seems better to error on vault-add and show a warning on user-del (if possible) that the vaults and containers must be manually removed. This would prevent adding an initial orphan and/or prevent adding new ones for already deleted users.
I've opened https://fedorahosted.org/freeipa/ticket/5674 to reflect comment 6. It will be resolved according to the triage. Since the proposal will be resolved elsewhere I'm closing this bug again.