Affects Version/s: None
Fix Version/s: None
Component/s: Promise type: files
I will describe the steps that led here:
- I built a package on my build slaves a couple of times while making fixes.
- Then I removed all traces of the build in @/var/cfengine@ and then installed the package.
- I bootstrapped which gave me the following message:
R: You are running a hard-coded failsafe. Please use the following command instead.
"/var/cfengine/bin/cf-agent" -f /var/cfengine/inputs/update.cf
notice: Q: ".../cf-agent" -f u": error: Can't stat file '/var/cfengine/inputs/controls/3.8/update_def.cf' for parsing. (stat: No such file or directory)
Q: ".../cf-agent" -f u": error: Policy failed validation with command '"/var/cfengine/bin/cf-promises" -c "/var/cfengine/inputs/update.cf"'
Q: ".../cf-agent" -f u": error: CFEngine was not able to get confirmation of promises from cf-promises, so going to failsafe
notice: Bootstrap to '192.168.123.13' completed successfully!
- No matter how many times I made sure that @/var/cfengine/masterfiles/controls/3.8/update_def.cf@ existed before bootstrapping, it always resulted in this error.
Here's what really happened:
- There is a section, @cfe_internal_update@ in @failsafe.cf@ which uses a shortcut to try to copy masterfiles from the hub. If it fails (which is expected on the hub, since it doesn't connect to a server), it triggers a different promise which uses the full path.
- However, for me it succeeded, but it copied the wrong files.
What happened is that I happened to be in the build directory, which has the directory "masterfiles" in it. This resulted in the copy_from promise using the relative path "masterfiles" of the current directory instead.
Although I can't see any security implications because of this, it is not good, since the agent behavior will depend on where in the file tree the user is. And generally accepting relative paths in the policy which is run as root does not sound like a good idea.