On 1/19/21 9:04 PM, Ben Nemec wrote:
There was also a security concern with potentially having multiple policy files and it not being clear which was in use. If someone converted their JSON policy to YAML, but left the JSON one in place, it could result in oslo.policy using the wrong one (or not the one they expect). We decided it was better for each project to make a clean switchover, which allows for things like upgrade checks that oslo.policy couldn't have itself, than to try to handle it all in oslo.policy.
IMO, that's a downstream distro thing.
What I did in Debian (and for Victoria already) was having the postinst of each package to rename any existing policy.json into a disabled version. Here's an example with Cinder:
if [ -r /etc/cinder/policy.json ] ; then mv /etc/cinder/policy.json /etc/cinder/disabled.policy.json.old fi
and then package the yaml file as (example from Nova): /etc/nova/policy.d/00_default_policy.yaml
and then setting-up this: policy_dirs = /etc/nova/policy.d
The reason I'm doing this way, is that I'm expecting upstream to generate a commented-only yaml file, and final users to drop non-default supplementary files without touching the package default file.
So, someone upgrading to Victoria with a non-default policy.json will see its manual tweaks go away, but not completely gone (ie: recoverable from disabled.policy.json.old).
Does this seem to be a correct approach?
On Wed, 2021-01-20 at 00:25 +0100, Thomas Goirand wrote: that seams kind of dangorus to me or at least unexpected if i have custom policy and i upgrade i dont expect that to revert back to default policy. if it does not exists autogeneratin a default policy.yaml with everything commented could work but im not sure if that is better then leaving it blank and insted generating on in /usr/share/<project>/policy.yaml.example i dont have a strong oppion on this approach beyond that really. i just find it unintuitve. what you descibe i guess would make sense if you had the popup whwere it ask do you want to use teh package maintaners version if you do that implictly without askign the user i would be concerned it will either break there production system if they had replaxed the policy constarits or added new roles or worse expose capablities they had locked down. so what ever you do make sure its telegraphed well.
Cheers,
Thomas Goirand (zigo)