App Store Tips, Tricks, and Hacks for the SysAdmin
App Store, oh, App Store, like all Apple products you are made first for consumers and in time maybe you will be ready for corporate deployment, but for now, here’s some tips for the Mac IT worker needs to wrangle this beast.
Firstly, the App Store, if you’ve noticed, requires admin rights to download and install apps. Not just because it installs to /Applications (it could be ~/Applications if it wanted to…) But most likely due to the new location of the receipts folder in /var/db/receipts. Up until version 10.6 it was /Library/Receipts and this would have made it possible to use the domain system that was the simple genius of OS X, where things can live in /System/Library, /Library, or ~/Library and when the system couldn’t find a pref or support file in one domain it would look in the next. Fonts are a great example of this in action, why didn’t they think it was a good idea for receipts is anyone’s guess. But since there is no way to make an analogous folder structure of /var/db/receipts in a user’s home folder, much less have the system recognize there are receipts there, the App store is not “Standard User” compatible.
Disabling Execution and hiding the App Store with Unix Permissions:
#hide it
sudo chflags hidden /Applications/App\ Store.app/
#keep it from executing for anyone other than root (since it is ownership is root:wheel)
sudo chmod o-x /Applications/App\ Store.app/Contents/MacOS/App\ Store
#to let admin users execute, next change group ownership of executable
sudo chgrp admin /Applications/App\ Store.app/Contents/MacOS/App\ Store
#OR keep anyone from executing it
sudo chmod ugo-x /Applications/App\ Store.app/Contents/MacOS/App\ Store
Keeping the icon from populating the Dock is more troublesome, since Apple has changed this from 10.5, previous versions, it was a matter of altering /System/Library/User\ Template/English.lproj/Library/Preferences/com.apple.dock.plist but this no longer exists. I am searching for where this information is pulled… but in the meantime you could use a utility like RemoveItemFromDock to run for a user when they log in (note: a new user will not have a com.apple.dock.plist file until their first login, this makes it tricky for login scripts on first login…) I had a good lead in /Library/Preferences/com.apple.dockfixup.plist but removing the add-app entry that contains the path to the App Store did not help… wah wah.
Well, so you hidden the App Store, restricted it running, but what can your sneaky users do?
They can buy an App Store app on their home computer and then simply copy it to their work laptop. The app will prompt them to authorize it with their AppleID, boom, done, no problem for a Standard User. However, they will not get updates on the computer, since there is no receipt of its installation, this would need to be done manually. User bringing in paid apps to a work computer creates a quandary for admins who run app inventory on computers (especially if it’s for license compliance)! From my attempts at pruning and tinkering with the Parental controls MCX values in the user’s records there didn’t seem to be a way to wildcard the white or blacklist, however it is promising that there is a boolean key call appStore that shows up. But for now enabling “Limit Applications” setting involves explicit approval for EVERY app they want to run that’s not on the whitelist, and personally I don’t care if you want to run Primate Plunge to waste time during conference calls – you and I will probably be saner for it. :)
Bottomline MCX doesn’t seem to have a straightforward way to deal with this now that doesn’t involve more admin overhead using Parental Controls.
Perhaps though, you don’t care what your user intalls from the App Store but you care enough that they are still Standard Users, well here’s the hack and slash way to enable them to use the app store…
How to Allow Standard Users to Run the App Store*
*Disclaimer: !!!WARNING!!! Security settings are changed with this action!!!! HACK AT YOUR OWN RISK !!!!!
#Make the App store an SUID binary so it runs as root *
sudo chmod +s /Applications/App\ Store.app/Contents/MacOS/App\ Store
#Change rights in /etc/authorization to allow system.privilege.setugid_appkit right by anyone* **
sudo cp /etc/authorization /etc/authorization.saved
sudo cp /etc/authorization /etc/authorization.plist
sudo defaults write /etc/authorization rights -dict-add system.privilege.setugid_appkit '<dict><key>rule</key><string>allow</string></dict>'
sudo plutil -convert xml1 /etc/authorization.plist
sudo sudo chmod go+r /etc/authorization.plist
sudo mv /etc/authorization.plist /etc/authorization
There you go, your standard users can now install App Store apps.
*Disclaimer: !!!WARNING!!! Security settings are changed with this action!!!! HACK AT YOUR OWN RISK !!!!!
** When you Google this, you’ll find this is the same solution I found for using Flip4Mac with Compressor as a standard user. I just love reusable code ;)
I hope you learned something and even better I hope you might have some insight to add that I’ve missed, please send in your comments, thanks!
Putting it all back the way it was before we started messing around
sudo chmod u=rwx,go=rx /Applications/App\ Store.app/Contents/MacOS/App\ Store
sudo chown root:wheel /Applications/App\ Store.app/Contents/MacOS/App\ Store
sudo chflags nohidden /Applications/App\ Store.app/
mv /etc/authorization.saved /etc/authorization
Update: My removeitemfromdock script seems to have been thrown by a loop by changes to the dock plist, just like I had to work around Dashboard when it was itroduced to the Dock in a new way. Update to come…
Update-2: removeitemfromdock now works like a charm, my Dashboard hack was taking for granted that Dashboard is not always at position 0 after the Finder, so when App Store snuck in behind, it was getting skipped, now there are some robust kludges to deal with Dashboard’s non standard dock entry
“no receipt of it’s installation” should be:
“no receipt of its installation”.
Indeed, it required a possessive pronoun not a plural! In another sentence I had done the complete opposite, I hate to
looselose control of my grammar like that,itsit’s so embarrassing… how could I have mist that? ;)I am looking for the location of the Receipts for transactions on the App Store.
I have Snow Leopard installed.
The App Store App seems to think I have an update for an app that I have never downloaded.
Could you point me in the right direction
P
Hey, good question, haven’t had time to look into that and I’m curious myself (but on vacation with only my iPhone :) All receipts for Snow Leopard are kept in /var/db/receipts I would think App Store apps use this location as well. You could find out by running fseventer while you install a free app and see where it writes the file, just be sure to shut down every running app or it could get quite “noisy”, good luck! Write back and let me know what you find! Thanks.
Looks like in addition to storing receipts in /var/db/receipts/bundlename.[plist and bom] the App Store also stores its install history in here /Library/Receipts/InstallHistory.plist the same plist used for Software Updates. Coincidentally it is a plist that is unable to be used with defaults, it’s structured in the same way as the XProtect plist.
I’ve run these commands and still get an “The application with bundle ID com.apple.appstore is running setugid(), which is not allowed.” error. Have I stuffed it or have Apple changed their permissions structure? PS. Great work by the way. I hate to seem ungrateful…
I’ve been trying to get this functioning for us and AppStore refuses to open. An error message shows up in the console saying that AppKit Apps aren’t allowed to setugid.
Did I break it or have Apple changed things?
Hmm, apparently they’ve changed something in 10.6.8 (perhaps other versions since I posted), running App Store as standard user with password has been patched. In a way I’m flattered to think the folks at Apple might be reading this blog :D
This topic got real popular with Lion coming out eh? Anyway sorry I guess 10.6.8 added some checks to App Store, so that it won’t run if the binary is a a SetUID password.