Comment 7 for bug 1308834

> I think you wouldn't want to have some other user put your stack into a persistent DELETE_FAILED state

Well then arguably they should have policy enforced separation between the users, as even if we hard-code something which prevents this scenario, the user could easily do anything else like abandon or update the stack (if they're allowed to even try deleting it)

> Would it be possible to authorise the user before attempting to delete?

Well yes, but only if we hard-code an assumption of stack-owner-or-admin which matches what's currently in keystone.

I'm not actually sure why that enforcement is done in the code and not the policy in the keystone trusts code, but obviously it only makes sense for us to hard-code something which is likely to stack hard-coded in keystone - if that check moves to the policy (where, arguably, it should be), then we can't enforce it as we don't have visibility of the potentially deployer modified policy rules.

Another possibility might be to try deleting the trust first and fail deletion before deleting any other resources if the stack-deleting user lacks rights to delete the trust? This would still end up in a DELETE_FAILED state, but would avoid enforcing policy in the engine code, while failing in a less interruptive way.