Home | Software | Adobe PressReady in OS X

Font Finagler | dfontifier | Repair Disk Utility's Permissions

Repair Disk Utility's Permissions Repair Disk Utility's Permissions

Version 3.0, January 17, 2004
Copyright © 2004-2017 Mark Douma. All rights reserved.

Product Requirements:

What's new in this version:

Product Description:

One of the more ironic permissions issues in OS X Jaguar is when the permissions of the Disk Utility application itself become corrupted. This can prevent you from being able to use Disk Utility's "Repair Permissions" tab to repair the permissions on your disk, including those of the Disk Utility application itself. Repair Disk Utility's Permissions can fix this corruption which would result in the following type of "Operation not permitted" errors reported in the Repair Permissions' progress window:

User differs on ./Applications, should be 0, owner is 501
Group differs on ./Applications, should be 80, group is 99
Owner and group not corrected on ./Applications, reason Operation not permitted
Permissions not corrected on ./Applications, reason Operation not permitted

NOTE: It's unnecessary to run Repair Disk Utility's Permissions in Mac OS X Panther 10.3.x and later. The reason for this is that Apple has changed the way Disk Utility works in order to prevent this catch-22 situation from occurring in the first place.

When you launch Disk Utility (both in Jaguar and in Panther), there are actually 2 separate executables that launch (refer to the table below). In Jaguar, these two processes are "Disk Utility" and "Disk Utility Agent" which both reside in the Disk Utility application bundle. Normally when you launch an application, it runs at the level equal to the user who launched it. For example, since my user name is 'mdouma46', when I launch an application like Mail, it runs at the "mdouma46" user level, and is able to do anything that I am able to do. Another way to put that is it's not allowed to do anything that I'm not allowed to do. For instance, it's not allowed to delete a file in the SYSTEM DOMAIN (/System/ folder) without first requiring me to authenticate in order to gain the privileges necessary for modifying that folder. There is, however, a way to specify before you launch a process, the user-level at which that process should run. That method involves the use of the "SetUID" (Set User ID) flag for an executable file. When that flag is set for an executable, OS X ignores who launched the executable, and instead, looks to the actual ownership of the executable file itself, and launches the executable as a process that's running at that level. As you can see in the table below, Jaguar's Disk Utility has 'root' (aka 'system') ownership along with the SetUID flag, so it launches at the root user level. It only runs at root level for an instant, during which time it launches the secondary "Disk Utility Agent" process, which, since it was launched by Disk Utility which is running at the root level, takes on root level running permissions as well. As soon as Disk Utility has finished launching Disk Utility Agent, it then lowers its own effective user id (EUID) to the regular user level. The Disk Utility executable handles most of the superficial things, such as when you resize the main window, or navigate through the menu commands. Those types of things don't require special privileges or permission to complete, so there's no sense in having the Disk Utility executable running at root level when it doesn't need to be, so it lowers itself down. Disk Utility Agent is the part of Disk Utility that handles the actual verification and repair of your disk, and verification and repair of the permissions of your disk, and so it therefore requires root-level privileges. So, without the root ownership and SetUID bit set for it, the Disk Utility executable won't be able to launch Disk Utility Agent process at the correct root-level, which will cause "Operation not permitted" errors when trying to repair the permissions on your disk. The reason the SetUID bit is used is simply for sake of convenience, so that you're not required to type your password while starting Disk Utility, in order to authenticate to a higher privilege level.

OS Executable owner special initial run level final run level
Jaguar Disk Utility.app/Contents/MacOS/Disk Utility root SetUID root level user level
Disk Utility.app/Contents/Resources/Disk Utility Agent root -- root level
Panther Disk Utility.app/Contents/MacOS/Disk Utility root -- user level
/System/Library/PrivateFrameworks/DiskManagement.framework/Resources/DiskManagementTool root SetUID root level

In case you're completely confused by that last paragraph the situation described above is analogous to the following situation: Your boss at work chooses to appoint you to be the boss, and then they themselves choose to resign, take a pay cut and assume the ranks a little lower down on the scale.

In Panther, things are slightly different with the Disk Utility application. While the end result is the same (two separate processes, one running at normal user level and the other running at root level), the method used to achieve it is slightly different, and, in general, makes it less likely that the catch-22 situation that can happen in Jaguar will happen in Panther. Panther's Disk Utility uses 2 separate processes as well, which are "Disk Utility" and "DiskManagementTool" (again, refer to the table above). While the "Disk Utility" executable has root ownership, since it doesn't have the SetUID flag set, that becomes irrelevant, and it launches at the regular user level. After it starts, it then launches the secondary tool, the "DiskManagementTool" executable, which, since it has root ownership and the all-important SetUID flag set, runs at the root level. As you can see from the table above, this secondary tool is tucked away in the System Domain, making it less likely to suffer from the same issue that can sometimes happen in Jaguar.

Explanation:

I ran into this "Operation not permitted" problem a while back. It happened when I accidentally deleted my entire Utilities folder and had gotten a copy of the Disk Utility application from a friend's machine. It turned out that copying it from my friend's machine actually altered (corrupted) the file permissions of the Disk Utility application itself, thereby rendering a catch-22 situation where Disk Utility couldn't do its job due to a lack of proper permission settings. I suppose it would be nice if Disk Utility could repair its own permissions if they go awry.

Anyway, the cause of this problem is that the 'root' ownership and the "SetUID" flag have been lost on the actual Mach-O executable of the Disk Utility application itself. The Mach-O executable needs to have its user set to "root" so that when it runs (with the SetUID bit set) it takes on root power, thereby enabling it to alter the permissions on other files if need be.

In other words, what this flag basically does is give the Disk Utility application a higher level of authority to allow it to make changes to your disk. Trying to run Disk Utility without that flag set or with the wrong "user" value can cause most operations to fail with permission errors.

Directions for use:

Double-click Repair Disk Utility's Permissions to launch it. If you aren't running OS X 10.2.0 - 10.2.8, you'll receive an error message informing you of such (Repair Disk Utility's Permissions is only necessary and applicable to the Disk Utility application of Jaguar).

Repair Disk Utility's Permissions will check the existing permissions of your Disk Utility application. If they're fine, you'll be informed that repair is unnecessary. If they're damaged, Repair Disk Utility's Permissions will then check the permissions of the "/usr/bin/sudo" file. If the permissions of "sudo" are also damaged (which could be the sign of widespread permission corruption), the permissions on your OS X installation are too severely damaged for Repair Disk Utility's Permissions to be able to fix them. (This is because, in order for us to change the owner of a file to "root", we must be the "root user" ourselves. The "sudo" file is the tool that allows us to temporarily become root, provided, of course, that its permissions aren't damaged as well. You might think of it in the following way. Under most circumstances, you'd never be able to fire your boss. Instead, your boss must either choose to quit themselves, or your boss's boss can fire them. That's the way it works with permissions too.) If the permissions of "/usr/bin/sudo" are also damaged, then you'll need to start up from your OS X 10.2 install CD or Restore CD/DVD disc and run Disk Utility's "Repair Permissions" feature from that. To do this, insert your Mac OS X CD or Restore CD/DVD disc, then restart the computer while holding the C key. Once started up from CD/DVD, choose Disk Utility from the Installer menu.

So, provided that the permissions of Disk Utility are currently damaged, and the permissions of "usr/bin/sudo" are fine, Repair Disk Utility's Permissions will proceed with the repair procedure. If Disk Utility is running, you will be warned of this and it will be quit before proceeding. You will be prompted for your password as Repair Disk Utility's Permissions executes 2 commands in the background in order to repair Disk Utility's permissions. It will then report whether it was successful or not. If successful, Repair Disk Utility's Permissions will launch Disk Utility for you and then quit. Remember, if all else fails, you can always start up from your Install or Restore CD/DVD, and run Disk Utility from there.

Support:

If Repair Disk Utility's Permissions gives an error "Cannot get text 1 thru 25 of """, it means that your copy of Disk Utility has been renamed, moved, or is missing and Repair Disk Utility's Permissions cannot find it. To repair this type of situation, you'll need to get the copy of Disk Utility off of your install CD or restore DVD and copy it to your hard drive into the /Applications/Utilities/ folder. Then, you'll need to (re)install the Combo-type update equal to the version of OS X you're currently using. That will update the Disk Utility application to the version equal to that which you should have for your current version of OS X.

If you have questions about other permission-related problems, I'd encourage you to check out any of the forums listed below:

Apple Discussions
Macfixit Forums
MacNN Forums
Mac OSX Hints Forums

Disclaimer:

This application is provided "as is" with no warranty expressed or implied. Under no circumstances shall Mark Douma be liable for direct, indirect, special, incidental, or consequential damages resulting from the use, misuse, or inability to use this software.

Thanks, and I hope this helps....

Version History:

Version 3.0 January 17, 2004

Version 2.0 December, 2003

Version 1.0 October, 2003