{"id":244,"date":"2011-01-14T12:33:55","date_gmt":"2011-01-14T18:33:55","guid":{"rendered":"http:\/\/www.brunerd.com\/blog\/?p=244"},"modified":"2011-01-21T10:31:41","modified_gmt":"2011-01-21T16:31:41","slug":"app-store-tips-and-tricks-for-sysadmins","status":"publish","type":"post","link":"https:\/\/www.brunerd.com\/blog\/2011\/01\/14\/app-store-tips-and-tricks-for-sysadmins\/","title":{"rendered":"App Store tips and tricks for sysadmins"},"content":{"rendered":"<div>\n<div>\n<h1>App Store Tips, Tricks, and Hacks for the SysAdmin<\/h1>\n<p>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&#8217;s some tips for the Mac IT worker needs to wrangle this beast.<\/p>\n<p>Firstly, the App Store, if you&#8217;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&#8230;) 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\u00a0use the\u00a0<a href=\"http:\/\/developer.apple.com\/library\/mac\/#documentation\/MacOSX\/Conceptual\/BPFileSystem\/Articles\/Domains.html\" target=\"_blank\">domain system<\/a> that was the simple genius of OS X, where things can live in \/System\/Library, \/Library, or ~\/Library and when the system couldn&#8217;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&#8217;t they think it was a good idea for receipts is anyone&#8217;s guess. But since there is no way to make an analogous folder structure of \/var\/db\/receipts in a user&#8217;s home folder, much less have the system recognize there are receipts there, the App store is not &#8220;Standard User&#8221; compatible.<\/p>\n<h4>Disabling Execution and hiding the App Store with Unix Permissions:<\/h4>\n<p><code>#hide it<br \/>\nsudo chflags hidden \/Applications\/App\\ Store.app\/<\/code><\/p>\n<p><code>#keep it from executing for anyone other than root (since it is ownership is root:wheel)<br \/>\nsudo chmod o-x \/Applications\/App\\ Store.app\/Contents\/MacOS\/App\\ Store<\/code><\/p>\n<p><code>#to let admin users execute, next change group ownership of executable<br \/>\nsudo chgrp admin \/Applications\/App\\ Store.app\/Contents\/MacOS\/App\\ Store<\/code><\/p>\n<p><code> <\/code><code>#OR keep anyone from executing it<br \/>\nsudo chmod ugo-x \/Applications\/App\\ Store.app\/Contents\/MacOS\/App\\ Store<br \/>\n<\/code><br \/>\nKeeping 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&#8230; but in the meantime you could use a utility like <a href=\"http:\/\/www.brunerd.com\/software\/RemoveItemFromDock\/RemoveItemFromDock.dmg\">RemoveItemFromDock<\/a> to run for a user when they log in (note: a new user will not have a\u00a0com.apple.dock.plist\u00a0file until their first login, this makes it tricky for login scripts on first login&#8230;)\u00a0I had a good lead in\u00a0\/Library\/Preferences\/com.apple.dockfixup.plist\u00a0but removing the\u00a0add-app\u00a0entry that contains the path to the App Store did not help&#8230; wah wah.<\/p>\n<p>Well, so you hidden the App Store, restricted it running, but\u00a0<strong>what can your sneaky users do<\/strong>?<\/p>\n<p>They\u00a0can\u00a0buy 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.\u00a0User bringing in paid apps to a work computer creates a quandary for admins who run app inventory on computers (especially if it&#8217;s for license compliance)! From my attempts at pruning and tinkering with the Parental controls MCX values in the user&#8217;s records there didn&#8217;t \u00a0seem 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 &#8220;Limit Applications&#8221; setting involves explicit approval for EVERY app they want to run that&#8217;s not on the whitelist, and personally I don&#8217;t care if you want to run\u00a0<a href=\"http:\/\/www.aelius.com\/primateplunge\/\" target=\"_blank\">Primate Plunge<\/a> to waste time during conference calls &#8211; you and I will probably be saner for it. :)<\/p>\n<p>Bottomline MCX doesn&#8217;t seem to have a straightforward way to deal with this now that doesn&#8217;t involve more admin overhead using Parental Controls.<\/p>\n<p>Perhaps though, you don&#8217;t care what your user intalls from the App Store but you care enough that they are still Standard Users, well here&#8217;s the hack and slash way to enable them to use the app store&#8230;<\/p>\n<h4>How to Allow Standard Users to Run the App Store*<\/h4>\n<p><strong>*Disclaimer: !!!WARNING!!! Security settings are changed with this action!!!! HACK AT YOUR OWN RISK !!!!!<\/strong><\/p>\n<p>#Make the App store an SUID binary so it runs as root *<\/p>\n<p><code>sudo chmod +s \/Applications\/App\\ Store.app\/Contents\/MacOS\/App\\ Store<\/code><\/p>\n<p>#Change rights in \/etc\/authorization to allow system.privilege.setugid_appkit right by anyone* **<\/p>\n<p><code>sudo cp \/etc\/authorization \/etc\/authorization.saved<br \/>\nsudo cp \/etc\/authorization \/etc\/authorization.plist<br \/>\nsudo defaults write \/etc\/authorization rights -dict-add system.privilege.setugid_appkit '&lt;dict&gt;&lt;key&gt;rule&lt;\/key&gt;&lt;string&gt;allow&lt;\/string&gt;&lt;\/dict&gt;'<br \/>\nsudo plutil -convert xml1 \/etc\/authorization.plist<br \/>\nsudo sudo chmod go+r \/etc\/authorization.plist<br \/>\nsudo mv \/etc\/authorization.plist \/etc\/authorization<\/code><\/p>\n<p>There you go, your standard users can now install App Store apps.<\/p>\n<p>*Disclaimer: !!!WARNING!!! Security settings are changed with this action!!!! HACK AT YOUR OWN RISK !!!!!<\/p>\n<p>** When you Google this, you&#8217;ll find this is the same solution I found for using Flip4Mac with Compressor as a standard user. I just love reusable code ;)<\/p>\n<p>I hope you learned something and even better I hope you might have some insight to add that I&#8217;ve missed, please send in your comments, thanks!<\/p>\n<h4>Putting it all back the way it was before we started messing around<\/h4>\n<p><code>sudo chmod u=rwx,go=rx \/Applications\/App\\ Store.app\/Contents\/MacOS\/App\\ Store<br \/>\nsudo chown root:wheel \u00a0\/Applications\/App\\ Store.app\/Contents\/MacOS\/App\\ Store<br \/>\nsudo chflags nohidden \/Applications\/App\\ Store.app\/<br \/>\nmv \/etc\/authorization.saved \/etc\/authorization<\/code><\/p>\n<p>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&#8230;<\/p>\n<p>Update-2: <a href=\"http:\/\/www.brunerd.com\/software\/RemoveItemFromDock\/RemoveItemFromDock.dmg\">removeitemfromdock<\/a> 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&#8217;s non standard dock entry<\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>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&#8217;s some tips for the Mac IT worker needs to wrangle this beast. Firstly, the App Store, [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,4,12,8],"tags":[],"class_list":["post-244","post","type-post","status-publish","format-standard","hentry","category-apple","category-os-x","category-scripting","category-security"],"_links":{"self":[{"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/posts\/244","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/comments?post=244"}],"version-history":[{"count":15,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/posts\/244\/revisions"}],"predecessor-version":[{"id":255,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/posts\/244\/revisions\/255"}],"wp:attachment":[{"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/media?parent=244"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/categories?post=244"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.brunerd.com\/blog\/wp-json\/wp\/v2\/tags?post=244"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}