[Douglashh]

I did my periodic Repairing of Permissions tonight. I usually have 0 to 2 files whose permissions are repaired in addition to the ACL's. Tonight about 10 files from Core Services/frontrow and maybe 15 from Frameworks/iphotoaccess said they were repaired. I ran Disk Utility again just to make sure. Same ones shown as repaired. Ran a 3rd time with the same frontrow and iphotoaccess files repaired.

I never use Frontrow.

Any ideas why Disk Utility is not working? I'm running 10.5.6.

[CharlesS]

You don't need to periodically repair permissions. 5 bucks says that your Front Row and iPhoto files' permissions aren't anything that will cause any problems at all.

But if you want to prove it, just copy and paste the log from Disk Utility into this thread.

edit: Okay, being the nice guy I am, I decided to run Repair Permissions myself and see if it would happen on my machine too. Sure enough, it does - a bunch of CodeResources files have permissions of lrw-r--r-- instead of -rw-r--r--. This is because the apps and frameworks containing these files are code-signed, and in 10.5.0, the code signature was stored in a file called CodeResources inside the bundle's Contents folder. However, in one of the 10.5.x updates, the standard location for the CodeResources file changed to be inside a folder called _CodeSignature. However, in order to allow the code signing still to work on earlier versions of 10.5.x, a symbolic link was put in the old location that points to the new location. However, since the file is now a symlink instead of a regular file, the permissions mode is going to start with "l" and thus be different from what was originally installed. This is just another example of how Repair Permissions reporting something only tells you that the file's permissions are different from what was originally installed, not necessarily that they are wrong. The permissions of those files are perfectly correct, regardless of what RP thinks, and you can't do anything about it. Unfortunately for you, everyone knows that people whose permissions don't exactly agree with Repair Permissions get their entire families hauled off to Guantánamo by the Repair Permissions Cops. Oh wait, that's not true - actually nothing bad will happen at all. Relax.

Lessons learned:

1. Stop running Repair Permissions periodically. You only need to run it if you are experiencing a problem of some sort.

2. Don't freak out if Repair Permissions reports something. Permissions are not voodoo, and aren't really that likely to be the cause of problems (especially ones in places like /System that don't typically change).

[Douglashh]

I was just concerned because my 'clone' of 3 weeks ago does not report anything accept the ACL's.

Sorry for posting in the wrong forum - wasn't sure which one was correct since repairing permissions seemed like and OSX thing.

[Douglashh]

Update: Booted into my clone and Repaired Permissions. Nothing but ACL's. I knew my last clone was prior to the FrontRow 2.1.7 update and those were some of the files not being repaired by Disk Utility so I ran Software Update and installed the FrontRow 2.1.7 update.

Repaired Permissions and bingo there were all the Front Row and IPhoto Access files showing as being repaired. Repaired Permissions and they still showed as being repaired.

I guess all is well. Thanks for the informative and detailed post CharlesS.

[Art Vandelay]

There have been Front Row and iPhoto updates within the last few weeks. The updates are the likely source of the change that CharlesS explained.

[Hal Itosis]

While it's all good and well to scold users for repairing permissions too often, the comments above very kindly overlook the shoddy workmanship which was revealed by recent updates. Had the permissions database (in Leopard) been properly updated to reflect those new changes, such spurious error messages wouldn't appear... and there'd be nothing to post about in the first place.

[CharlesS]

There is no "permissions database". It reads the information out of the installer receipts (I think it mainly uses the SQLite database in /Library/Receipts/db, but it's possible that it could use the boms for something as well), and it always uses the receipts from the original Mac OS X installation. I'm not sure exactly how it determines which receipts are original and which have been added more recently, but If it let update packages override the originals, then it would be possible for third party packages to override them as well, which would kind of defeat the whole purpose of the thing. Some idiot could make a package that set the permissions of /Applications to 000, and then even if you fixed that by hand, Repair Permissions would happily set the permissions back to 000 every time you ran it. The better solution is just to use Repair Permissions for what it's intended for, a tool to run if you are experiencing some kind of problem related to permissions, instead of treating it like some sort of periodic "maintenance" utility and freaking out about its progress messages (which aren't "errors" either).

[Hal Itosis]

Originally Posted by CharlesS 

There is no "permissions database". It reads the information out of the installer receipts (I think it mainly uses the SQLite database in /Library/Receipts/db,

There is no "permissions database"? Golly, gee, and shucks... so sorry i didn't use the full pathname.
Just to avoid future confusion, that's precisely what i meant by the "permissions database".

Originally Posted by CharlesS 

but it's possible that it could use the boms for something as well), and it always uses the receipts from the original Mac OS X installation. I'm not sure exactly how it determines which receipts are original and which have been added more recently,

possible that it could . . . ?
not sure exactly how . . . ?
Interesting... thanks.

Originally Posted by CharlesS 

but If it let update packages override the originals, then it would be possible for third party packages to override them as well, which would kind of defeat the whole purpose of the thing. Some idiot could make a package that set the permissions of /Applications to 000, and then even if you fixed that by hand, Repair Permissions would happily set the permissions back to 000 every time you ran it.

So, are you saying that Apple employs no mechanism in Leopard which allows their newer packages to override original perms?
[yes or no?]
Because it appears to me that they do. For example, just look at the output from

pkgutil --file-info /private/etc/cups

and you'll see how the gid was changed to 0 (during the 10.5.3 to 10.5.5 period).
Not coincidentally, the following message would appear when people reset perms (until the recent 10.5.6 update):

Group differs on "private/etc/cups", should be 0, group is 26.

Besides, what you said about 3rd-parties overriding /Applications is bunk.
Apple manages perms based only on what's in *Apple* updates & installs.

Anyway, once given an admin password an app can do whatever it wants,
so your entire argument there is specious at best.

Originally Posted by CharlesS 

The better solution is just to use Repair Permissions for what it's intended for, a tool to run if you are experiencing some kind of problem related to permissions, instead of treating it like some sort of periodic "maintenance" utility and freaking out about its progress messages (which aren't "errors" either).

Why are you arguing against something which no one is even trying to contend?
Who's the one whose freaking out?

[CharlesS]

Originally Posted by Hal Itosis 

There is no "permissions database"? Golly, gee, and shucks... so sorry i didn't use the full pathname.
Just to avoid future confusion, that's precisely what i meant by the "permissions database".

It's the receipts database.

possible that it could . . . ?
not sure exactly how . . . ?
Interesting... thanks.

Not sure what point you're trying to make here, if any.

So, are you saying that Apple employs no mechanism in Leopard which allows their newer packages to override original perms?
[yes or no?]

Not that I'm aware of.

Because it appears to me that they do. For example, just look at the output from

pkgutil --file-info /private/etc/cups

and you'll see how the gid was changed to 0 (during the 10.5.3 to 10.5.5 period).
Not coincidentally, the following message would appear when people reset perms (until the recent 10.5.6 update):

Group differs on "private/etc/cups", should be 0, group is 26.

I just tried it, and on mine it changes the group for /private/etc/cups to 26, although oddly enough it doesn't log anything while doing it.

Besides, what you said about 3rd-parties overriding /Applications is bunk.
Apple manages perms based only on what's in *Apple* updates & installs.

It manages them based on the original packages; I haven't seen any cases where the updates were able to override the originals. We used to get threads every once in a while in which someone would claim about permission "errors" because an update package changed something, and RP changed it back.

There's no way to prove that a package actually came from Apple short of using code signing, which is actually possible with Leopard's package format but which Apple oddly enough doesn't seem to be using (at least with the 10.5.6 package, which I just checked).

Anyway, once given an admin password an app can do whatever it wants,
so your entire argument there is specious at best.

Yes, but whatever they do won't be subsequently propagated every time you run Repair Permissions, unless they're doing it by hacking the receipts database, which is somewhat far-fetched.

Why are you arguing against something which no one is even trying to contend?

People running Repair Permissions periodically and getting concerned when things show up in its log is what causes threads like this one.

Who's the one whose freaking out?

You, apparently, since you seem to be trying to make a big fight out of this, which is really not what I want to be doing right now.

[goMac]

Originally Posted by Hal Itosis 

While it's all good and well to scold users for repairing permissions too often, the comments above very kindly overlook the shoddy workmanship which was revealed by recent updates. Had the permissions database (in Leopard) been properly updated to reflect those new changes, such spurious error messages wouldn't appear... and there'd be nothing to post about in the first place.

You do realize the irony of this statement is that because permissions are read from the receipts database, they are always up to date, and always match the latest update, right?

[Hal Itosis]

Originally Posted by CharlesS 

I'm not sure exactly how it determines which receipts are original and which have been added more recently, but If it let update packages override the originals, then it would be possible for third party packages to override them as well, which would kind of defeat the whole purpose of the thing. Some idiot could make a package that set the permissions of /Applications to 000, and then even if you fixed that by hand, Repair Permissions would happily set the permissions back to 000 every time you ran it.

That quaint notion (3rd-party receipts overriding Apple's settings) must be based on some old pre-Tiger memories. Disk Utility has been ignoring them for quite a while now (see 2nd paragraph). Pluswhich, as Charles should also well remember: the HintFile.plist (mid-Panther) has allowed Apple to override their own original permissions for years now. Though that precise file (HintFile.plist) is no longer in use... no doubt a similar scheme exists for Leopard. A peek at the pkgutil man page indicates but one way it could possibly be implemented (--learn).

I can understand why a lounge lizard like goMac may not be up on all this... but a developer of a commercial package utility should certainly be more informed. It's one thing to be real particular about how pronouns are pronounced (correcting my casual "permissions database" slang to insist on the perfect "receipts database" -- not just once, but twice) -- however, it would be more beneficial if such trivia was accompanied by a better overall understanding of how it all works (today... not 6 years ago), along with a sharing of that information. [As opposed to reactive-mind mudslinging, armed with only mythical hypotheticals.]