Comment 17 for bug 1837877
Revision history for this message
| Matt Riedemann (mriedem) wrote Re: Error message reveals ceph information | #17 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
7020100
(Get the code!)
Ugh, OK. So in this particular case, the instance goes to ERROR state from the reboot failure here:
https:/
The exception is re-raised and the fault (libvirtError) gets recorded by the wrap_instance_fault decorator:
https:/
This is what sets the message field on the InstanceFault:
https:/
This is likely where the libvirtError gets turned into the message:
https:/
Trying to play whack-a-mole with all of the places that could raise unexpected exceptions from lower layers, like the hypervisor in this case, is going to be a losing game. We should probably just restrict the fault message to admin-only since we don't audit them and this is python so explicitly handling typed exceptions isn't a thing.
Deciding *where* to obfuscate the message is the question I think. We could say that for any non-NovaException types (where format_message() is implemented), we could just include the message if context.is_admin here:
https:/
But that won't fix old compute nodes until you patch them. It also doesn't mean that NovaExceptions handled here:
https:/
Wouldn't also expose something from a lower level because we have several exceptions like this:
https:/
Where whatever lower level error happens gets turned into the "reason" value.
Given that, it probably makes most sense to just add a new policy rule that is checked in the API to determine if the fault message can be shown here:
https:/
And the policy rule would default to admin-only. A policy rule is better since deployments could tailor it so non-admin support personal could still see those details but not the tenant user that owns the server.
If we do that, I'd also fix the logic here so we rely on policy rather than this janky code logic:
https:/