What exactly is verifying disc permissions? What does it mean when they differ?
Well, the MacOS uses a permission-based file system. This means that only certain users can access certain files. (In this case, users refers to those with separate login names). This helps protect your files against unwanted intrusions. In order for the OS to work correctly, it has to have permission to use certain files. The “Verify Disc Permissions” option will check and see if the files have been set correctly. The “Repair Disc Permissions” option will actually fix them.
When it says they “differ”, it is wanting you to fix them.
Sources, and for more information:
http://www.thexlab.com/faqs/durepairfns.html
Wiki:
Permissions differ on the following:
./Applications/iTunes.app/Contents/Frameworks/InternetUtilities.bundle/Contents/MacOS/InternetUtilities
./Library/Application Support/Macromedia/Shockwave 10/Shockwave 10 Preferences
./Library
./private/var/log/secure.log
Seems like half the time I update iTunes the permissions change.
EDIT: Oh – I always repair them, and have done this time as well.
The other thing permissions control is whether a file is executable. That is, the operating system will treat the file as something that can be “run.” Executable files can contain machine code, scripts, byte code (i.e. compiled java code) and the like. Files self identify the mechanism by which they are run (i.e whether to: directly loaded and execute, create a script interpreter and point it at the script, create a virtual machine and point it at the bytecode file). In all cases a new process is created to hold the run mechanism. The point is that unless the file has “execute” permission set, the OS will refuse to run it. Execute permission is available, like all Unix permissions as User, Group, and Others. So you can control who can execte the file. Even if you own a file, and have read and write permission set, the OS won’t run it unless it has execute permission set.
The other permission is how Unix style OS’s control system level actions in a secure manner. The OS requires that some programs are able to perform priviledged actions, even when run by a mere mortal user. Such programs are trusted, and we assume they have been very carefully written, and tested, so that they won’t do anything bad, wrong, or provide some backdoor mechanism to allow a malicious user to escalate their privilege, and thus compromise the system. There is an additional permission - set-uid. Which the OS interprets as meaning that, when executed, the process that the program is running in, runs as the user that owns the file, and not the user that requested that the program run. So, a file that is set-uid, and owned by “root” - the privileged user - will run with full system wide access ability. A large part of this ability comes because other parts of the system are accessed via their presence in the file system (for instance, devices live in /dev and look life files - even though they aren’t real files) and are owned by root. So the set-uid process can now access them in a controlled manner, even though a normal user can’t. If the permissions on these critical system programs is messed up the OS will fail to work properly.
A simple example of a set-uid program is the Activity Monitor. It uses access to the file in /dev that provides access to the OS kernel’s internal state, and can read information about the current activity of the OS directly out of there. Normally access to this special file is restricted - since it is possible to find important secure information (like passwords in clear text) in there. But the program is trusted to only do what is needful and no more.
I find it hard to understand how MacOS manages to allow permissions to get screwed up. But it does happen.
Checking permissions can only be done on files that Apple knows about. Apple provides a database with what the permissions are “supposed” to be, and then checks against that. Of course, that database only contains information on OS files, and Apple-supplied applications. Often, permission errors are benign - the system will happily run with permissions that are looser than they are supposed to be, but may have serious issues if permissions on critical files get set to read-only (for example). People today use “repair permissions” like old-time Mac users used “rebuild desktop” - a cure-all for whatever ails you. I’ve found that repairing permissions almost never fixes a problem, but there have been a few notable exceptions - I cured a particularly obnoxious HP “refuse to print” bug by repairing permissions; one of the files that had it’s permissions messed up was the HP printer driver.