Skip to content

FMA install scripts for macOS apps ignore some errors #50056

Description

@jkatz01

Fleet versions

Web browser and operating system: N/A (affects macOS hosts)


💥 Actual behavior

macOS Fleet-maintained app install scripts don't check the exit code of the command that installs the app, so a failed install still exits 0 and Fleet reports it as installed successfully.

Image

🛠️ Expected behavior

If installer -pkg or cp -R fail in the install script it should return with a failure exit code

🧑‍💻 Steps to reproduce

These steps:

  • Have been confirmed to consistently lead to reproduction in multiple Fleet instances.
  • Describe the workflow that led to the error, but have not yet been reproduced in multiple Fleet instances.
  1. Add the Microsoft Excel FMA (microsoft-excel/darwin) to a fleet.
  2. Make the install command fail while leaving the rest of the script intact — edit the installer's install script so the sudo installer -pkg line points at a filename that isn't the downloaded package (e.g. change Microsoft_Excel_16.111.26071325_Installer.pkg to Microsoft_Excel_0.0.0_Installer.pkg), keeping the trailing relaunch_application 'com.microsoft.Excel' line.
  3. Install Excel on the host.
  4. Check the install activity: it reports "Fleet installed Microsoft Excel" with install_script_exit_code 0, and the script output contains installer: Error - the package path specified was invalid below Fleet's "Success" line.

For the cp -R variant, do the same with Firefox (firefox/darwin), pointing the final sudo cp -R at a source path that doesn't exist.

Also reproducible via the steps in #49811 before the fix for that is merged.

🕯️ More info (optional)

Both install mechanisms the script generator emits are affected — 963 of the ~966 macOS FMA scripts. The only exceptions are 1password, logitune, and slack, which propagate the exit code by accident because the install command happens to be their last line.

Scripts that use installer -pkg:

sudo installer -pkg "$TMPDIR"/Microsoft_Excel_16.111.26071913_Installer.pkg -target / -applyChoiceChangesXML "$CHOICE_XML"

relaunch_application 'com.microsoft.Excel'
  • installer exits non-zero and prints its error, but the exit code is never captured or checked.
  • relaunch_application runs next and returns 0 (it returns early when the app wasn't running).
  • It's the script's last command, so the script exits 0.
  • Fleet treats exit 0 as success.
  • 120 of 123 installer -pkg scripts.

Scripts that use cp -R:

yes | hdiutil attach -plist -nobrowse -readonly -mountpoint "$MOUNT_POINT" "$INSTALLER_PATH" || exit 1
sudo cp -R "$MOUNT_POINT"/* "$TMPDIR"
hdiutil detach "$MOUNT_POINT" || true
quit_and_track_application 'org.mozilla.firefox'
if [ -d "$APPDIR/Firefox.app" ]; then
	sudo mv "$APPDIR/Firefox.app" "$TMPDIR/Firefox.app.bkp"
fi
sudo cp -R "$TMPDIR/Firefox.app" "$APPDIR"
relaunch_application 'org.mozilla.firefox'
  • hdiutil attach is guarded with || exit 1, so a mount failure is caught — but the cp -R that performs the install is not.
  • If the copy fails (no space, unwritable /Applications, missing source), the app isn't installed or is left partially copied.
  • The existing app was already moved aside to .app.bkp and is never restored, so a failed copy can leave the host with no working app.
  • relaunch_application follows and returns 0, so the script exits 0 and Fleet reports success.
  • 867 of 867 cp -R scripts.

Other notes:

  • Both patterns come from one generator, ee/maintained-apps/ingesters/homebrew/scripts.go (installScriptForApp, InstallPkg), so the fix is per-pattern rather than per-app, plus regenerating ee/maintained-apps/outputs/*/darwin.json.
  • Not fixed by Fix false-success reporting for failed software installs #49515 (issue Failed software installs are reported as successful #49475), which makes a non-zero install-script exit terminal. These scripts exit 0, so that rule never fires.
  • Any failure mode of the install command is hidden this way (bad path, insufficient space, corrupt package, refused signature, unwritable target). FMAs trying to install wrong version of app #49811 is one way to make the command fail; this issue is why the failure is reported as success.
  • Windows FMA scripts are not affected: they run the installer through Start-Process ... -Wait and Exit $installProcess.ExitCode.

Metadata

Metadata

Assignees

Labels

#g-auto-patchingProduct group focused on auto patching softwareP1Critical: Broken workflow (critical bug), potential vuln, new feature for immediate Fleet needbugSomething isn't working as documentedcustomer-panoramixcustomer-sanchezfmarelates to a Fleet-maintained app

Type

No type

Projects

Status
Done

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions