So… I got a free copy of Office 2008 Digital Media Edition for free at MacWorld 2008! W00t! All because IDG double booked a room and the session I wanted got bumped until later. I instead went to see what’s new at the “Office2008:Form Meet Function” session, cute sounding eh? Within the first minute or two, to ensure our rapt attention I’m sure, our lady MC told us that we were all going to receive a free copy of Office 2008. Except, without the same flair as Oprah (she should have tried stretching it out: “You’re all getting Awwwwwww-Fiiiiiiiiiiiiiiiiice!!!”) Oh well, it still felt nice to win something, especially something as pricey as the Digital Media Edition which runs $467 at CDW! I got back yesterday and after debating whether I’d sell this bad boy or install it, I went with carnal knowledge of the beast.
First things first: They’ve moved to Apple’s Package Maker (.pkg) installer files, good news for the enterprise rollouts? Well, unfortunately they’ve created all the packages to install most all of the files with the owner set to 502.
So let’s say, Mr. IT installs this on a user’s machine where the first user is the admin (501) and the standard user is Joes User (502), well, when after all’s installed, it will give Joe User (502) ownership of these folders and their installed contents:
/Library/Automator/ (if it doesn’t exist already)
/Library/Fonts/Microsoft
/Library/Application Support/Microsoft
/Applications/Microsoft Office 2008
Hmmm, that’s not good now is it? Because A) Joe User will find a way to screw it up and B) those are security holes IT does not want to have. Oh, if only they’d taken a peek at p. 1060 of Cocoa Programming, which basically says, if you let root own the file but the person installing isn’t root, it will assign that user’s id to the installed files, that’s how it should be. Instead if UID 502 doesn’t exist on your system when you install it will still assign that UID as the file’s owner anyway. D’oh!
I think I feel a chown’ing script (or an Iceberg repackaging) coming on and an uninstaller script too. “But, there’s an Uninstaller!”, you say? Yes there is and it does a lovely job of moving the Microsoft Office 2008 folder to the Trash, but it kinda misses the Application Support folder, the fonts folder (and moving the disabled fonts back), and all 97 automator actions… tsk tsk. Still, it was free!
Morning Update: It was late, I was tired (and sick), and I totally didn’t think of this one: “Fix Permissions”. If you do get your ownership fixed on all those files, make sure to delete all the Office2008* files from your /Library/Receipts folder, lest you reverse it all with one click of “Fix Permissions” in Disk Utility. And no, you can’t use awk, sed, or some other readily apparent way to modify the bom files… that’s someting for the MOAB crew ;)
Flabbergasting! Is that a word? Anyway it is. Great work!
Thanks for the heads up, this could be a very serious headache.
“Repair Permissions” in Disk Utility should not undo the changes you make to the Office 2008 or any other third-party product installation. See the “Does Disk Utility check permissions on all files?” heading in
Apple KB 25751.
How can they scew something as big ??????
I guess it explains A LOT of things about MS….
About your update :
Fix permissions doesn’t fix these files.
It only fixes OS files. It doesn’t affect user installed apps or files.
That leaves us with a nice script to come up with…
Yes, thank you for sharing.
[sarcasm]
I find it odd not to see any ‘deployment’, ‘payloads’ or ‘resources’ directories next to the actual installer. Where’s the Bootstrapper.dmg? Is this stuff actually something you can install on a Mac?
[/sarcasm]
The other thing to keep in mind is that, if you really are using this in the enterprise, your user IDs are probably managed by Open Directory or some such, in which case they start at 1000. So no users should ever get assigned 502.
For example, I have one local admin on the machine (ID 501) and then any other home directories are portable and managed via OD.
Not that this isn’t dumb, I’m just sayin’….
Yep. I am definitely waiting for SP1.
Sure enough. I don’t see a /Library/Automator, though.
Wow, good catch.
One correction: The Repair Disk Permissions function in Disk Utility shouldn’t reverse your fixes, since it doesn’t use third-party receipts when “repairing” permissions.
Why did you see this and not someone within MS? For such a high-profile release you’d think they’d QC better.
It’s fun to blame Microsoft for everything, but the truth is that this is a long-standing flaw in Apple’s Installer. For details see:
http://www.stepwise.com/Articles/Technical/Packages/InstallerOnX.html
Maybe MS should have known better, but maybe Apple should also have improved their installer years ago. Apple clearly hasn’t cared enough about smaller developers to make a fix, so hopefully MS has a high enough profile that something finally gets done.
The MacBU is aware of this issue.
Schwieb
MacBU Dev Lead
Thanks for the corrections on the receipts folks. Also, as for the Automator actions, they aren’t included with the Home & Student editions. And Thank You, Erik, for letting us know you folks in the Northwest have heard our ruckus.
If we do the following, will it break the uninstaller?
sudo chown -R root:admin /Library/Fonts/Microsoft
sudo chown -R root:admin /Library/Application\ Support/Microsoft/
sudo chown -R root:admin /Applications/Microsoft\ Office\ 2008/
Dear Son of mine,
I love reading these. I hear you voice as I read them. One question. Why are you not working for them, Microsoft? I am very proud of you.
Love, Mom
“but the truth is that this is a long-standing flaw in Apple’s Installer.”
You’re kidding? It’s not a flaw, it’s a feature. It is the responsibility of the person creating a package to define what permissions should be used. Not being able to figure out the files should be owned by root:admin is like not figuring out that you need to power on a Mac to use it.
Ummm, no. Repairing Permissions won’t change a thing on non-Apple software, even if it was installed using Apple’s Installer app.
Required reading: http://unsanity.org/archives/000410.php
Thanks for all the “3rd party reciepts aren’t checked comments”, got it. I could have sworn I saw some Xerox PPDs get corrected (at work), but I think that was a case of the Xerox drivers overwriting the Apple supplied ones. Ever since then I had it in my head that Disk Utility would look at other pkg receipts. But as for unsanity… they cause their own set of problems with APE, and unfortunately that tarnishes my view of anything they have to say.
“It is the responsibility of the person creating a package to define what permissions should be used.”
No, it is you who is joking. It is *my* machine, not Microsoft’s or some random third-party developer’s, and *I* get to set what I want. If you’d actually read the link I provided, you’d have seen that the problem lies in the fact that Apple’s Installer will blindly change ownership and permissions. If I wanted to make /Library/Automator/ a+w and owned by group 666 on my machine (for whatever stupid reason), nobody should be changing that without my permission. It is flat out *wrong* for Apple’s software to allow that because it could cripple your whole machine.
“files should be owned by root:admin”
For 99.999% of the software that gets released, it should be able to be installed and run as the current user. It should be the *exception* that software has an installer at all, let alone one that alters permissions by default. Apple simply dropped the ball, and has done so on this issue for years, and you should not defend them in this matter.
Not Required,
You are wrong on this one. If you want more control than your OS, then it is your responsibility to know and understand the ramifications of that choice. The design, as it stands, allows for the most seamless, least problematic installation and use of software by any user on a given machine. You may lock down that functionality if you wish, but it should not be the default on end-user machines destined to be used by your neighbors mom or grandmother.
You will find this privilege setting idea no different on Linux, HPUX, Solaris, what-have-you… It’s up to you, if you want to override the default privileges, to do so. Not everyone else that has a user account on the machine.
If you want to set the perms for /Library/Automator, then remember to run your post repair script to set those perms back. Scripting isn’t that hard for you, or you wouldn’t be in the CLI to begin with.
Remember that this is Unix-land. A multiuser privilege protected environment. Under your scenario any additional users will not be able to make use of what should be software accessible by all users of the machine without your direct intervention.
You seem to think that everyone would love to have to intervene in such cases because you find you want to.
>”It is *my* machine, not Microsoft’s or some random third-party developer’s, and *I* get to set what I want.”
That’s where you’re just dreaming. There are permissions and ownerships to conform to when building an installation package. If someone plans to install stuff in /Applications or /Library, then the owners have to be root:admin. The permissions should be 775 for folders, 664 for non executable files, etc. It’s not democracy here, it’s security and common sense.
For the record, PackageMaker (or WreckageMaker depending on how much you like this app) includes a tool to check files permissions and ownership against common recommendations.
And anyway, are they not doing QA testing in the MacBU?
Finally, I don’t see why people are that agitated because of this mistake. It’s not as bad as an Intuit update who deleted user’s desktop.
“If you want more control than your OS, then it is your responsibility to know and understand the ramifications of that choice.”
You support my point! It’s about *my* control and not, in this case Microsoft’s control, or *any* random developer’s control. Apple should not be handing off control of your computer to any fool that can create a package, yet that is exactly what they’ve been doing.
“The design, as it stands, allows for the most seamless, least problematic installation and use of software by any user on a given machine.”
Yeah, if you ignore the fact this very article exists for you to respond to. Apple’s own advice is that you should not need an installer to run an app, and I would absolutely agree that there is *nothing* about an office suite that requires administrative access.
“Under your scenario any additional users will not be able to make use of what should be software accessible by all users of the machine without your direct intervention.”
No, under my scenario an individual wouldn’t have to become administrator to use an app themselves, and the *optional* system-wide installation *might* involve getting *write* access to *particular* folders. There is simply no sane reason for an installer to blindly start changing ownership and permissions of entire directory trees. If you can’t refute that very basic point, stop making yourself look bad by trying to make Apple look good.
Apple’s own documentation (http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/SoftwareDeliveryGuide.pdf) says on page 32 that “In most cases, the owner should be root and the group admin.”
By the way, I’ve posted a blog entry to Mac Mojo with some terminal commands to fix the file ownership issues. The exec bit issues are hard to fix with a simple terminal command, but we’ll be fixing both in a pending software update.
http://www.officeformac.com/blog/Security-issue-in-Mac-Office-2008-Installer
I think /Library/Automator exists on Automator savy companies which are generally DTP houses to deploy company specific automator scripts to all users on a machine.
Now, if Automator exists there and magically chowned to 502, anyone having 502 (generally,the non admin first account for safety) will have right to deploy any Automator script there. E.g. “convert this file to PDF” could well be rm the file.
I hope I am understanding something wrong but it seems this issue.
Also MS BU may have proved the causes of decade old ex NeXT and Mac developers still staying away from Apple pkg format saying it is way too powerful in a bad way.
Speaking about wrong permissions, someone should see the ever ongoing scandal of Adobe (and Macromedia, before) to install Flash with wrong permissions in each build.
Sorry for double comment but something really interesting. Intego people, makers of Virusbarrier _fixed_ the MOAB issue of SUID binaries via simple virus definitions update. That was a great way of proactive fixing things.
Now there is a 502 installed thousands of files issue and as everyone probably knows, not every software user actually cares about updating their system yet alone an office package.
Why wouldn’t Intego which asks $70 for an antivirus program on OS X doesn’t do the same trick as a favour for their paying customers? It is not someones “I am 133t, showing OS X issues” thing like MOAB, it is a very widely installed, top seller office software.