Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Repairing permissions after 10.5.8 update extreme oops maybe???

Ok I understand that there is still the issue of Repairing permissions regarding hard code links no big deal. Apple still has not fixed this in this update.

The problem that I have at the moment is understanding why the dbase is not updated properly it appears.

After applying the update to two separate machines both intel based and running Repair permissions through Disk Utility which is what I always do after any os update, there were some very strange oddities that pertains to core files and even after reboots and rechecking seferal times there is no change.

Someone at Apple messed up I think and did not update the permissions dbase during or after the update. I also used the Combo updater versus the smaller regular update as I always do to to avoid some intermittent occasional install problems some tend to see when using the smaller updaters.

Anyone else seeing this and how big of an issue is it to have it show for core files permissiona "should be ?--------- ," ??

Below is an example and is on both an iMac 24" and a MacBook Pro:

Reading permissions database.
Reading the permissions database can take several minutes.
...... I cut out the standard stuff we are used to seeing with the links "l" permisions

Permissions differ on "System/Library/Frameworks/AppKit.framework/Versions/C/_CodeSignature/CodeResou rces", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonC ore.framework/Versions/A/_CodeSignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ CoreGraphics.framework/Versions/A/_CodeSignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/PrivateFrameworks/DotMacSyncManager.framework/Versions/A/_CodeS ignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/PrivateFrameworks/DotMacSyncManager.framework/Versions/A/Resour ces/DotMacSyncHelper.app/Contents/_CodeSignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/PrivateFrameworks/DotMacSyncManager.framework/Versions/A/Resour ces/dotmacsyncui.app/Contents/_CodeSignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/PrivateFrameworks/DotMacLegacy.framework/Versions/A/_CodeSignat ure/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/_CodeSignature/CodeDirecto ry", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/_CodeSignature/CodeResourc es", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/_CodeSignature/CodeSignatu re", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBEHCI.kext/ Contents/_CodeSignature/CodeDirectory", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBEHCI.kext/ Contents/_CodeSignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBEHCI.kext/ Contents/_CodeSignature/CodeSignature", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBHub.kext/C ontents/_CodeSignature/CodeDirectory", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBHub.kext/C ontents/_CodeSignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBHub.kext/C ontents/_CodeSignature/CodeSignature", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBMergeNub.k ext/Contents/_CodeSignature/CodeDirectory", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBMergeNub.k ext/Contents/_CodeSignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBMergeNub.k ext/Contents/_CodeSignature/CodeSignature", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBOHCI.kext/ Contents/_CodeSignature/CodeDirectory", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBOHCI.kext/ Contents/_CodeSignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBOHCI.kext/ Contents/_CodeSignature/CodeSignature", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBOpticalMou se.kext/Contents/_CodeSignature/CodeDirectory", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBOpticalMou se.kext/Contents/_CodeSignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBOpticalMou se.kext/Contents/_CodeSignature/CodeSignature", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBUHCI.kext/ Contents/_CodeSignature/CodeDirectory", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBUHCI.kext/ Contents/_CodeSignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBUHCI.kext/ Contents/_CodeSignature/CodeSignature", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/IOUSBCompositeDriv er.kext/Contents/_CodeSignature/CodeDirectory", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/IOUSBCompositeDriv er.kext/Contents/_CodeSignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/IOUSBCompositeDriv er.kext/Contents/_CodeSignature/CodeSignature", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/IOUSBHIDDriver.kex t/Contents/_CodeSignature/CodeDirectory", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/IOUSBHIDDriver.kex t/Contents/_CodeSignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/IOUSBHIDDriver.kex t/Contents/_CodeSignature/CodeSignature", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle/Co ntents/_CodeSignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/IOUSBUserClient.ke xt/Contents/_CodeSignature/CodeDirectory", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/IOUSBUserClient.ke xt/Contents/_CodeSignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/IOUSBUserClient.ke xt/Contents/_CodeSignature/CodeSignature", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBMassStorageClass.kext/Contents/_CodeSignature/C odeDirectory", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBMassStorageClass.kext/Contents/_CodeSignature/C odeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Extensions/IOUSBMassStorageClass.kext/Contents/_CodeSignature/C odeSignature", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/CoreServices/CCacheServer.app/Contents/_CodeSignature/CodeResou rces", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/CoreServices/Kerberos.app/Contents/_CodeSignature/CodeResources ", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/CoreServices/KerberosAgent.app/Contents/_CodeSignature/CodeReso urces", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/Frameworks/Kerberos.framework/Versions/A/_CodeSignature/CodeRes ources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/KerberosPlugins/KerberosDatabasePlugins/db2.bundle/Contents/_Co deSignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/KerberosPlugins/KerberosDatabasePlugins/kldap.bundle/Contents/_ CodeSignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/SystemProfiler/SPDisplaysReporter.spreporter/Contents/_CodeSign ature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/CoreServices/Screen Sharing.app/Contents/_CodeSignature/CodeResources", should be ?--------- , they are -rw-r--r-- .
Permissions differ on "System/Library/PrivateFrameworks/ScreenSharing.framework/Versions/A/_CodeSigna ture/CodeResources", should be ?--------- , they are -rw-r--r-- .

Permissions repair complete

G5, MBP. MB, and iMac 24", Mac OS X (10.4.11), Also 10.5.8 in some intel machines

Posted on Aug 5, 2009 7:22 PM

Reply
106 replies

Aug 5, 2009 7:53 PM in response to Stat

yes, I've seen it. I applied the delta update on one of my computers and it didn't exhibit such strange permissions messages afterwards. then I applied the combo update on my other computer and it showed such messages as you are seeing.

should be ?--------- , they are -rw-r--r-- .

I checked and the permissions repair process changes the permissions on all such files to 000 i.e. no permissions to anybody! this is most definitely wrong. i also checked and the permissions on all such files are most decidedly NOT 000 on my other system with the delta update. In particular I also got the same message as you did

Permissions differ on "System/Library/PrivateFrameworks/ScreenSharing.framework/Versions/A/_CodeSigna ture/CodeResources", should be ?--------- , they are -rw-r--r-- .

I checked the permissions on this file on the system updated using the delta update and they are 644 (i.e. -rw-r--r--) and the repair permissions process reports no errors on that system. I rolled back my other computer to my clone backup and updated it using the delta update and those strange messages went way. I thought it might be just a problem with my system but now that i see your post maybe not...

Anybody who sees such messages should know that this is NOT normal and should not be left alone. if you have a backup roll back as i did and reapply the delta update.

Message was edited by: V.K.

Aug 5, 2009 10:15 PM in response to V.K.

Yea it is strange, I did not have the time on the two operating systems to do a proper backup so I can not go back as you did.

I did reapply the delta update though over the top of one of the Combos and although I ended up with less apparently than with the original combo update there were still several.

One thing I did do was to go to the file level of this one which now reads "System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonC ore.framework/Versions/A/_CodeSignature/CodeResources", should be ?--------- , they are ---------
When inspecting that one the in the info window it now shows no more system or wheel and only everyone with the item marked as no access.

Considering that this is within the folder now called "_CodeSignature" and the root folder above this folder which is "A" has a CodeResources file inside it which has all the normal permissions set properly. I am wondering if this is something that was actually moved to this new folder instead of deleted and that the permissions tool may be looking at this file as it would with the parent folder if that makes sense. If this is part of the security updates portion why wouldn't Apple just remove it or is there something else going on that I am missing.

On the other side to note is that all of the files that are giving this error with permissions in the core files are all inside a folder called "_CodeSignature".

This may actually be nothing to worry about as it may be a way for the security patches to work properly to ensure the corrected resources are in place, If so though why are they not getting deleted with the updates as one would expect and why would this keep reappearing constantly and are these files in the "_CodeSignature" folders actually able to be trashed manually if Apple doesn't need them there and if they do then why are they set for no access?

Confusion is a wonderment uh?

Aug 6, 2009 1:30 AM in response to Stat

Same here on a fully-patched PPC PowerBook5,8.

Until this gets sorted out, I've created a shell script (called "unfix") containing a line for each of the "questionable" files of the form:
sudo chmod 644 /System/Library/CoreServices/Screen\ Sharing.app/Contents/_CodeSignature/CodeResources

From Terminal, run "chmod +x unfix" and then "./unfix". I'll try the delta update next. Sheesh.

Aug 6, 2009 2:05 AM in response to Richard Outerbridge

I too experienced this problem after applying the combo update. I then applied the delta update and was left with fewer such anomalies. After also scripting a 'chmod 644' fix to the remaining files I went on to script the following which was executed as root:

pkgutil --edit-pkg com.apple.pkg.update.os.10.5.8 --volume / --learn "offendingfile_fullpath"

A subsequent Disk Utility repair permissions showed no remaining problems.

Aug 6, 2009 4:44 AM in response to lobitz

lobitz wrote:
I too experienced this problem after applying the combo update. I then applied the delta update and was left with fewer such anomalies. After also scripting a 'chmod 644' fix to the remaining files I went on to script the following which was executed as root:

pkgutil --edit-pkg com.apple.pkg.update.os.10.5.8 --volume / --learn "offendingfile_fullpath"

A subsequent Disk Utility repair permissions showed no remaining problems.


Thanks. without a fix from Apple this is probably the cleanest way to deal with this. Note that if you used the combo update then in the above command put com.apple.pkg.update.os.10.5.8.combo

Aug 6, 2009 7:40 AM in response to Dogcow-Moof

William Kucharski wrote:
I wonder if Apple is changing the permissions to 000 on those files on purpose to make them unavailable without deleting them outright…

no, because on my systems that were updated using the delta update there are no such permissions repair messages and those same files all retain 644 permissions before and after running repair permissions.

Aug 6, 2009 8:09 AM in response to V.K.

V.K. wrote:
William Kucharski wrote:
I wonder if Apple is changing the permissions to 000 on those files on purpose to make them unavailable without deleting them outright…

no, because on my systems that were updated using the delta update there are no such permissions repair messages and those same files all retain 644 permissions before and after running repair permissions.


Did you happen to check the perms on those file after a 10.5.8 Combo update, but BEFORE running Repair Perms?

Aug 6, 2009 8:17 AM in response to Stat

Can someone with active AppleCare open a ticket on this issue to see if we should ignore this or manually fix it up?

Idea: has anyone tried doing the 10.5.8 Combo update again (after getting this issue). Does it fix these files up? If yes, then I just won't run Repair Perms after repeating the Combo update.

Aug 6, 2009 8:21 AM in response to mert

.
Did you happen to check the perms on those file after a 10.5.8 Combo update, but BEFORE running Repair Perms?

as a point of fact I did. ALL those files have 644 permissions after 10.5.8 combo but before running permissions repair. this is also true on my computer updated using the delta update. But while running permissions repair on that computer does not change permissions on those files, on the computers updated using the combo update the repair permissions process changes them to 000. as I said, this can not possibly be right. those files should have the same permissions no matter how you updated.

Aug 6, 2009 9:33 AM in response to mert

mert wrote:
Idea: has anyone tried doing the 10.5.8 Combo update again (after getting this issue). Does it fix these files up? If yes, then I just won't run Repair Perms after repeating the Combo update.


I tried re-applying 10.5.8 Combo and it does fix the files.
If I run "find -x / -perm 000" on the Terminal, nothing comes up.
Now I just have to remember not to run Repair Permissions until this gets resolved... in 10.5.9??

Aug 6, 2009 9:39 AM in response to Stat

I don't know if this fixes the problem, but it did for me. I used the combo update and got the same permission issues. I tried using the delta and had the same thing.

I restarted the computer with the shift key down (safe boot), reinstalled the Combo update. After that was finished, I ran disk utility again to repair disk permissions. It listed the permissions issues. I ran Repair disk permissions again I got this:

*Repairing permissions for “Macintosh HD”*
* Reading permissions database.*
* Reading the permissions database can take several minutes.*


*Permissions repair complete*


So far it good for me.

Repairing permissions after 10.5.8 update extreme oops maybe???

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.