# Repair Disk Permissions not working?



## VNJ85 (Feb 24, 2006)

I just recently ran repair disk permissions and I got a bunch of "will not be repaired" messages. I don't know what they mean but I have a hunch they don't mean anything good...

If there are any smart Mac users here maybe you can help me out.

Repairing permissions for “Macintosh HD”
Warning: SUID file "usr/libexec/load_hdi" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/DiskManagement.framework/Versions/A/Resources/DiskManagementTool" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Resources/Locum" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/Install.framework/Versions/A/Resources/runner" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/readconfig" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/writeconfig" has been modified and will not be repaired.
Warning: SUID file "usr/libexec/authopen" has been modified and will not be repaired.
Warning: SUID file "System/Library/CoreServices/Finder.app/Contents/Resources/OwnerGroupTool" has been modified and will not be repaired.
Warning: SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" has been modified and will not be repaired.
Permissions repair complete


I have no idea how or what went down, is anyone able to explain any of this?


----------



## Orion (Apr 16, 2004)

If you run Permission Repair again, do they still show up? If you haven't done the 10.5.1 update many of these may be a result of the slightly less-than-perfect .0 version of Leopard.


----------



## infinity8 (Feb 19, 2006)

You need not worry they cause no harm.
Mac OS X 10.5: Disk Utility's Repair Disk Permissions reports issues with SUID files


----------



## VNJ85 (Feb 24, 2006)

i'm up to date on updates. and i've run it many times just to see..

well thank goodness no harm, i was worried for a bit since i have had some recent slowdowns and issues.

now i am just flat out curious what they mean!


----------



## biovizier (Dec 21, 2005)

> now i am just flat out curious what they mean!


It's really a long story, but basically, in combination with some default settings used by Apple, the way "repair permissions" used to work posed a security risk. Apple is trying to address the issue, but it hasn't been fully implemented.

Executables with certain permissions, specifically those that are 'setuid' and owned by "root" will run as "root" regardless of who runs them - i.e. that executable has access to every file on the system. This is an extremely powerful state, and potentially dangerous if not used with care so certain safeguards are built in - normally, only "root" can make an executable 'setuid', and if any 'setuid' file becomes modified by someone other than "root", it loses its 'setuid' status.

The problem in the past was that if "repair permissions" found a programme at a certain location that had lost its 'setuid' status, it would happily make it 'setuid' again without checking to make sure that the file at that location was in fact the file that was supposed to be there. Since some of these 'setuid' executables were located in places that could be modified by a default OS X user without providing a password, this meant that eg. a trojan could switch out one of the accessible 'setuid' files with its own malware, and take over the system. And of course, "repair permissions" (which can make files 'setuid') doesn't require "root" privileges to run so that's another no-no by Apple. This issue was one of those highlighted by MOAB last January.

In 10.5, SUID files all have their sha1 checksums entered into a database, and this database is consulted while running "repair permissions". If a given file's sha1 hash doesn't match what is recorded for it in the database, "repair permissions" prints the SUID message. If the file's permissions are incorrect, then it won't repair them either.

Now consider what happens when a 'setuid' file is updated. The new file's sha1 won't match what's in the database, so the database will have to be updated or else the file will be perceived to have changed. However, in the case of eg. 10.5.1 via "Software Update", the database wasn't updated correctly so the SUID warnings appear where they shouldn't. Normally, "OS X" system updates replace / install whole files. However, the 10.5.1 update ("Software Update" version) actually patched the executables, rather than replacing them whole. I'm not sure of the details, but the installer apparently unpacks the patch into a temporary folder, and somehow that "patch" is applied to the target file. It appears that the sha1 of the patch is entered into the database, and not that of updated executable - from the installer's point of view, it seems to consider the "patch" to be the file that it installed, and hence it is the patch's path and sha1 that are recorded. It has been reported that the full 10.5.1 update (downloaded from Apple) makes the SUID messages go away - presumably the full update installs the whole file the old-fashioned way so the database gets updated correctly.

So as the article linked by "infinity8" says, the SUID messages as they pertain to the files specifically listed are likely not a cause for concern. But it is possible (though unlikely) that you have been hacked and one or more of those specific files were replaced by something else.

Also, if the SUID warning appears for any file not explicitly listed in the article, that is a cause for concern. This leads to another wrinkle in the "repair permissions" problem. My guess is that the sha1 database is consulted both when 'setuid' is expected (according to "correct" permissions), and when 'setuid' is actually encounted on a file, eg. if a file is found to be 'setuid' when it shouldn't be. This situation also causes the SUID warning message to appear (a file's sha1 can't match its value in the database if there is no entry for a file in the database - recall that only 'setuid' files have their sha1s included). The message can serve as a valuable warning that something in your system is not right, and that there is a potential security issue. However, one would hope that if a 'setuid' file is found where it shouldn't be, "repair permissions" would go to the next step and, well, repair the permissions, unset the 'setuid', and eliminate the security threat. Unfortunately, "repair permissions", as of 10.5.1, does not do this. Blindly "fixing" permissions to make an alterred executable 'setuid' is a security risk that "repair permissions" rightly avoids. On the other hand, not removing 'setuid' from a file that shouldn't have it is failing to remove a security threat, and that is bad.

As a real world example, if a user who has installed 10.5 via the "upgrade" option happens to "repair permissions" while booted in 10.4 (perhaps because it takes so long in 10.5), or while using "DiskWarrior", the permissions of some 10.5 system files will be set to 10.4 values. The list of 'setuid' files in 10.4 is different from 10.5, and in one such case - '/sbin/launchd' which is 'setuid' in 10.4 but not in 10.5 - the result is that user processes end up running as "root". A huge security issue, something that is entirely permissions based, and something not addressed by "repair permissions", at least as of 10.5.1.

So to answer the question in the thread title, I would say that "repair permissions" is not working.


----------



## VNJ85 (Feb 24, 2006)

Thanks biovizier!


----------



## Orion (Apr 16, 2004)

Wow. Very much appreciated, biovizier. Thanks ^_^v


----------



## biovizier (Dec 21, 2005)

Revisiting this old thread...

As a correction to my earlier post, unfortunately, it turns out that the actions downstream of the sha1 check were not actually implemented as I had thought. I think the description of the conditions that give rise to the warnings is still accurate, but what I thought would happen afterward doesn't, and "repair permissions" in Leopard (up to 10.5.6 anyway) overall is no more secure than earlier versions, and in some respects is less secure.


----------



## sharkman (Nov 26, 2002)

So would repairing permissions with something like Cocktail produce any better results?


----------



## eMacMan (Nov 27, 2006)

^^^ Cocktail or Onyx just provides another graphical interface for the unix terminal command, same as Disk Utility.


----------



## Guest (Oct 3, 2009)

biovizier said:


> Revisiting this old thread...
> 
> As a correction to my earlier post, unfortunately, it turns out that the actions downstream of the sha1 check were not actually implemented as I had thought. I think the description of the conditions that give rise to the warnings is still accurate, but what I thought would happen afterward doesn't, and "repair permissions" in Leopard (up to 10.5.6 anyway) overall is no more secure than earlier versions, and in some respects is less secure.


Appple _really_ has to get their act together with this as well as their whole app packaging system. Both components are integral and are in the dark ages as far as the tech they are using behind things goes


----------

