Adobe Flash 10 Installer launches Finder as root
Several web sites have begun requiring Flash 10 to play their content. This is partially because the PC version of Flash 9 had some security problems that I won’t get into here.
The good news:
Adobe provides their Mac version as a package installer.
The bad news:
There is a problem with Adobe’s Flash Player 10 installer for Mac. If you deploy using ARD, LANDesk or another deployment tool to machines that are sitting at the login window, the installer runs an applescript which will launch the Finder as the current user. Well, if you’re at the login window, that user is root. So the Finder launches behind the login window. If someone then logs in without the machine rebooting, the currently logged in user now has an instance of the Finder running as root with full root privileges. Some users will notice this because the contents of their home folder will be missing, logging out and logging back in will fix this.
Once way to fix this in the installer is to modify the postflight script within the in “Adobe Flash Player.pkg/Contents/Resources/” and comment out (add a # in front of the line) the following line:
osascript "$1/Contents/Resources/RemoveUserFPInstall.applescript"The ramifications of doing this are that Flash plugins that reside in the currently logged in users ~/Library/Internet Plug-ins will not be deleted and therefore would be used instead of the newly installed plugin in /Library/Internet Plug-ins. If this is a problem for you, you may want to modify the postflight further to look for and delete the plugin from each users home folder (without involving the Finder) like Adobe should have.
Adobe is not the only one that has an installer that launches the Finder at the login window. Two others that come to mind are Parallels and Flip4Mac. With theirs, they are just doing a simple “open /path/to/app/folder” to show the contents of what was installed so that’s easier to fix.
No related posts.
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.
Another interesting, related issue, is systems that launch System Preferences – and it’s an even weirder experience, sometimes. For instance, I have a script, here, that autoinstalls a new system’s software after the first boot post imaging, and one of the products that a particular client was having installed, was Growl. Growl, for the last step of the install, is supposed to open the Growl preference pane, so you can go configure it. Well, it tries to do that, when you push the pkg from the command line, with noone logged in, and what you get is the menu bar appearing above your login window, with System Preferences, supposedly, open. This gives the user access to several tools, without ANYONE being logged in – talk about a nightmare! Honestly, this seemed like an Apple bug to me – it’s a behaviour that should not be allowed to happen.
Same fix – go change the postinstall script.
You also might want to comment out this line in the preflight script:
“$1/Contents/Resources/CloseFPClients.app/Contents/MacOS/CloseFPClients”
That way you can perform the install with browsers open.