Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

10.6: Change Safari (and other) app icons System 10.6
I recently discovered, after trying to change Safari's icon, that Apple's apps in Snow Leopard have read-only permissions enabled for all users except root:wheel. This eliminates users' ability to use copy-paste replacement icons in the Get Info panel.

As a workaround I quit the Finder, and relaunched it as root in Terminal:
sudo /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder
I was then able to paste a replacement icon into Safari's Get Info panel. Then, after relaunching the Dock, my icon appeared.

[robg adds: You can quit the Finder using Activity Monitor and it won't restart. If you try this hint, remember to again quit the Finder and relaunch it as your normal user once you're done. I haven't tested this one, so I can't say if it breaks code signing or not.]
    •    
  • Currently 1.86 / 5
  You rated: 3 / 5 (14 votes cast)
 
[21,507 views]  

10.6: Change Safari (and other) app icons | 7 comments | Create New Account
Click here to return to the '10.6: Change Safari (and other) app icons' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.6: Change Safari (and other) app icons
Authored by: iGrouch on Sep 16, '09 08:55:03AM

You can also temporarily use Get Info to change the app to User ownership to change the icon with paste in the Get Info panel and then switch it back to System



[ Reply to This | # ]
10.6: Change Safari (and other) app icons
Authored by: palahala on Sep 16, '09 09:39:29AM

Note that if this breaks Code Signing, then applications might no longer be allowed to access the keychain, will no longer be permanently allowed an exception in the firewall if the application checks its own integrity (known to have caused trouble for configd, mDNSResponder and racoon), or might cause trouble when using software update.

(Above, might indicates that I am not sure.)



[ Reply to This | # ]
10.6: Change Safari (and other) app icons
Authored by: jalex on Sep 17, '09 05:33:07AM

More speculation here, but if the Finder should somehow have to recreate its preferences or a cache file or create any other file while it is running as a super user, it'll no longer be able to change/delete or possibly even read those files the next time it starts as your user. I'd use this hint with caution, and a willingness to use the Terminal to patch things up (possibly from another administrator account) if they break.



[ Reply to This | # ]
10.6: Change Safari (and other) app icons
Authored by: brh on Sep 17, '09 07:59:14AM

chown-ing apps so that your user actually owns them worked when I was testing out some things a while backů┬áDon't know if that is more or less likely to break code signing, or if it works in this specific case (changing icons - I was messing with something else in the package), but it may be another solution.



[ Reply to This | # ]
10.6: Change Safari (and other) app icons
Authored by: palahala on Sep 17, '09 01:09:06PM

To validate code signing, I guess something like the following will suffice?

$ codesign --display -vvv /Applications/Safari.app

For Safari 4.0.3 (on a 32 bit 10.6.1) that has not been altered, this yields:

Identifier=com.apple.Safari
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20100 size=10385 flags=0x0(none) hashes=513+3 location=embedded
CDHash=9336dad61b976ebcae24086ac089e9369ece4f79
Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist entries=27
Sealed Resources rules=10 files=493
Internal requirements count=1 size=316


[ Reply to This | # ]
10.6: Change Safari (and other) app icons
Authored by: palahala on Sep 27, '09 10:09:03AM

My earlier codesign --display -vvv is actually not useful to validate a signature: when using --display then nothing is validated at all. Remove that keyword and you'll see if the signature is valid:

codesign -vvv /Applications/iTunes.app/

Which yields either:

/Applications/iTunes.app/: valid on disk
/Applications/iTunes.app/: satisfies its Designated Requirement

...or:

/Applications/iTunes.app/: code or signature modified

Quick tests changing the icon for iTunes, Safari and Activity Monitor show no problems with Code Signing.



[ Reply to This | # ]
10.6: Change Safari (and other) app icons
Authored by: palahala on Oct 06, '09 10:36:02PM

Earlier I wrote "Quick tests changing the icon for iTunes, Safari and Activity Monitor show no problems with Code Signing". True: just pasting a new main icon using Finder's Get Info does not seem to break anything.

However, actually changing program resources (so, not just the application's main icon for Finder, but all icons an application uses) using third-party tools MIGHT break the signatures. Now, I don't know if that is a problem or not. Apparently, CandyBar (at least the old versions) breaks the signatures, but no problems seem to have been reported. Up till recently, MacUpdate showed a very old comment (dated January 10th 2008), from one of its developers:

As for changing your application icons by hand, you are more than welcome to do so! As a warning: if Apple enables the built-in code signing in a future Mac OS X minor update, your applications will simply no longer launch. This is what we're trying to safely avoid by disabling that feature until we get a sense from Apple of their plans.

This comment has now been removed, so I assume that Panic investigated (or even stalked Apple to get an answer) and did not find any problems either. I have not tested the new release of CandyBar to see if it still breaks the code signing. After installing any third-party tool, one can test using:

codesign --verify --verbose /System/Library/CoreServices/Finder.app
codesign --verify --verbose /System/Library/CoreServices/Dock.app

Maybe warnings like "a sealed resource is missing or invalid" are not as bad as "code or signature modified"?

As a side note: Ars Technica suggests that the code signing might (only?) have been introduced for the iPhone (in which applications might indeed not run or even install if the code signature is broken):

And let's not forget the "Mac OS X" technologies that we later learned were developed for the iPhone and just happened to be announced for the Mac first (because the iPhone was still a secret), like Core Animation and code signing.


[ Reply to This | # ]