Office 2008, 502, and you
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 
Rick said,
January 21, 2008 @ 11:39 am
Flabbergasting! Is that a word? Anyway it is. Great work!
Sean said,
January 21, 2008 @ 1:54 pm
Thanks for the heads up, this could be a very serious headache.
Phasor Burn » Blog Archive » MacBU - Ass clowns said,
January 21, 2008 @ 3:40 pm
[…] OMFG, what a laughable mistake the Mac Business Unit at Microsoft have made with their Office:Mac 2008 installer. I can’t believe they’re this bone-headed. […]
Histrionic said,
January 22, 2008 @ 1:53 pm
“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.
raphael campardou said,
January 22, 2008 @ 3:08 pm
How can they scew something as big ??????
I guess it explains A LOT of things about MS….
Raphael Campardou said,
January 22, 2008 @ 3:22 pm
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…
Adrian Nier said,
January 22, 2008 @ 4:04 pm
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]
Frank said,
January 22, 2008 @ 4:12 pm
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’….
joost said,
January 22, 2008 @ 4:30 pm
Yep. I am definitely waiting for SP1.
Jonathan Lundell said,
January 22, 2008 @ 6:27 pm
Sure enough. I don’t see a /Library/Automator, though.
DF said,
January 22, 2008 @ 8:20 pm
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.
Geeks R Us » Blog Archive » Office 2008 sets user ID to 502 said,
January 22, 2008 @ 8:42 pm
[…] Microsoft. I can confirm the report at bruned that the Microsoft Office 2008 installer sets the owner to user 502, which is the second user on […]
Joost said,
January 23, 2008 @ 2:34 am
Why did you see this and not someone within MS? For such a high-profile release you’d think they’d QC better.
Not Required said,
January 23, 2008 @ 9:54 am
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.
Erik Schwiebert said,
January 23, 2008 @ 4:16 pm
The MacBU is aware of this issue.
Schwieb
MacBU Dev Lead
brunerd said,
January 23, 2008 @ 4:40 pm
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.
Mike Connally said,
January 24, 2008 @ 6:50 am
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/
Cindy Smiley said,
January 24, 2008 @ 4:43 pm
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
Installer is innocent said,
January 25, 2008 @ 9:12 am
“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.
Leaman Crews said,
January 25, 2008 @ 10:39 am
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
brunerd said,
January 25, 2008 @ 11:19 am
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.
Not Required said,
January 25, 2008 @ 12:17 pm
“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.
Meat said,
January 25, 2008 @ 2:37 pm
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.
Microsoft confirms Office for Mac 2008 ownership snafu » D' Technology Weblog: Technology, Blogging, Tips, Tricks, Computer, Hardware, Software, Tutorials, Internet, Web, Gadgets, Fashion, LifeStyle, Entertainment, News and more by Deepak Gupta. said,
January 25, 2008 @ 2:38 pm
[…] Bruner, a Chicago-based Mac consultant, was the first to notice the ownership snafu. “[Microsoft] moved to Apple’s Package Maker (.pkg) installer files, good news […]
Installer is innocent said,
January 25, 2008 @ 6:13 pm
>”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.
Office 2008 de Leopar’dan farksız? - Mac Dünyası said,
January 25, 2008 @ 8:45 pm
[…] 2008’in kurulur kurulmaz neden olduğu problemi, ilk olarak Chicago’dan Joel Bruner tespit etti. Bruner’in tespitine göre, Office 2008, Mac OS X’te izinlerle ilgili önemli bir güvenlik […]
Not Required said,
January 26, 2008 @ 6:03 pm
“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.
Microsoft offers quick fix for Mac Office 2008 bug | OSX64 said,
January 26, 2008 @ 7:12 pm
[…] If you want further details visit Joel’s blogNote: I received my copy of Office 2008 on Monday but I have not had much opportunity to try it out. […]
Erik Schwiebert said,
January 26, 2008 @ 9:38 pm
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
Ilgaz said,
January 27, 2008 @ 5:54 am
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.
Ilgaz said,
January 27, 2008 @ 6:09 am
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.
Office 2008 updater 12.0.1 released. Post experiences here. - MacNN Forums said,
March 16, 2008 @ 11:56 am
[…] with a user ID of 502 (even if that ID didn’t exist on the system). A potential security flaw: brunerd Office 2008, 502, and you Betalogue Blog Archive Office 2008: Vital application files are owned by non-admin user ID […]