6

I used OSX's Disk Utility to Verify Disk Permissions and found a lot of system files had incorrect permissions. I'd say all of them were more open, allowing others to read or write. Also, many had the wrong group assigned. How does this happen?

2 Answers 2

4

My first guess would be: In most cases it's just lack of care from the programmer's side. Either because they are not thinking about it in the first place, or if something doesn't work, they might try to broaden permissions, even if it doesn't help. Consider applications that require you to enter the superuser password. What can they do with it, what will they do with it?

Well, let's see what we can find.

The official position:

Apple has a guide on Troubleshooting Permissions Issues, in which they say:

A third-party application installer incorrectly sets permissions on the files it installs, or even the entire Applications folder. [...] It is also possible that software installed while logged in as one user will be inaccessible when logged in as another.

Here's another reason:

The file system may be affected by a power interruption (improper shutdown) or when it stops responding (a "hang" or "freeze"). This could affect permissions.

Some applications might deliberately want to modify permissions in order to be able to "do more" on the system:

Most applications executed by a user only have access to the files that the user has access to. Backup software, for example, may not back up Mac OS X system files that have root ownership.

In general, it's not a bad idea to repair permissions on a regular basis. Can't hurt. Especially if you experience sudden troubles without apparent reason. Or if you want to make safe you don't accidentally modify or delete essential system files.

Then again, what are "correct permissions" anyway? Just because the Repair Permissions dialog says they're wrong, do they actually harm anything? Is there an increased security risk from wrong permissions? Probably not in 95% of all cases. Correct permissions are defined by the applications that are installed using "Receipts", which you can find under Library/Receipts or more recently under /var/db/receipts. Note that they are checked only for software installed using an Apple installer:

Files that aren't installed as part of an Apple-originated installer package are not listed in a receipt and therefore are not checked. For example, if you install an application using a non-Apple installer application, or by copying it from a disk image, network volume, or other disk instead of installing it via Installer, a receipt file isn't created.

Inofficial positions:

There are even some people who seem to be against repairing, but I'd not believe everything they say. There are a few reasons for incorrect permissions mentioned in the post:

The other number one cause of permissions going wonky were 3rd party installers that asked for root on OS X and changed permissions on some folders that were in the path to the destination. I know that [...] since updated their installers to prevent this kind of weirdness (these would be the same installers that told you to quit all applications when installing software on OS X)

So, any third party app can modify permissions and somehow incorrectly set them.

Basically what I said: Programming errors. In daily usage, a program might change file permissions. But imagine an installer or a program would actually set wrong permissions that cause serious trouble on the whole system – don't you think they'd fix this ASAP?

I haven't tried it, but go ahead, repair permissions, restart the Mac, then verify them. I'm sure something will need to be repaired again. Maybe people should not worry too much about it, unless they have a very specific security concern where they know which files are affected.

Home that shed some light on the subject.


Unsorted reading material:

2
  • The contradiction you mention is due to poor writing in the Apple Support document cited (HT1452). "Apple-originated installer package" is being used to mean "an installer package produced using Apple's toolchain (PackageMaker) that will be installed by Installer.app." If you look in /Library/Receipts yourself, you'll see pretty much nothing; all the action is in /var/db/receipts now. If you look there, you'll see receipts for packages that installed software from all vendors, not just packages that installed software produced by Apple (com.apple.*). May 26, 2011 at 13:14
  • Thank you very much, that makes more sense as I couldn't really verify it before - I adapted the post.
    – slhck
    May 26, 2011 at 13:23
1

Apple's PackageMaker has a reputation for not applying the permissions specified in its package design UI (see for example "Re: insufferable PackageMaker permissions defects", and Google for more). So if you trust Apple's developer software to work, your installer has a good chance of getting things wrong.

Older versions of PackageMaker expected the developer to build the entire directory hierarchy containing their application, and the installer would then apply the permissions that were on the Applications directory that the developer created. (For a how-to targeting an older version of PackageMaker that calls out precisely this problem, see WhiteBox's "PackageMaker How-To".) This was also easy to get wrong.

The correct permissions for various system files has also changed over time. For one minor example, see "Re: Permissions on Snow Leopard". This can render previously correct installers incorrect.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .