



This can be overridden to another user, but there’s an assumption that Munki is “managing” the installation of said application on the system. I use Munki to deploy all of our software, and typically one deploys apps to /Applications (when copied from disk images) using root:wheel ownership, because it’s considered a “system” install, not a user install. Nearly every one of the 100+ applications we install across my org needs some additional configuration to disable a built-in auto-updater. Dialogs like this are all too common for those who manage large numbers of computers, because of at least one of: 1) Users running the applications aren’t administrators and an application assumes they are, 2) An application assumes a user can modify files or the app bundle in /Applications, and that there may only be, in fact, one user using this application on the computer, or 3) An application has an auto-updater which is problematic to disable via a configuration profile or script.
