Repair Permissions....HOLY ****!!!!

[stoid]

I suddenly, and unexplainably couldn't get Activity Viewer to launch. It just popped into the dock and immediately faded away again. I tried the first 'obvious' solution and trashed to prefs. Nothing. I trashed them again and restarted the laptop. Nothing. I went to Disk Utility to Repair Permissions. I expected that as usual I would get a couple of files listed as needing a small permission fix. Instead, it changed permissions on about every single file and directory within my Application folder! I copied the log into a BBEdit text document and it 5.5MB of plain text!! What could POSSIBLY cause something like this to happen?!?

It seems that most of the changes are from -rwxrwxrwx to -rw-rw-r--. I'm no UNIX geek but it seems that means something like all admin/users/groups had full read/write access to all my files, and now it's set to proper file permissions.

Activity Viewer works now BTW.

 

[NusuniAdmin]

guess you should do it more often. I do most maintanence things once a week.

 

[yellow]

Repairing of permissions only needs to happen after an install that requires an admin password.

 

[wrldwzrd89]

Sometimes, little UNIX things go horribly wrong - for example, a program compilation script uses chmod to change permissions, but does it too broadly - so the permissions for lots of things get messed up. I have Carbon Copy Cloner (CCC) set to back up my hard drive daily at midnight, and repair permissions first, so I don't have to worry about such things.

 

[NusuniAdmin]

Repairing of permissions only needs to happen after an install that requires an admin password.

that is correct to a certain point but permissions can get screwed up for no reason, like someone else said when a program/script does chmod it might screw up, etc.

I wont even install anything since the last permission repair and i will still have crap loads of fixes.

 

[coconn06]

Repairing of permissions only needs to happen after an install that requires an admin password.

I've never had to Repair Permissions on my iBook, though I probably should just to make sure everything's clean.

I know a good amount of UNIX (so I understand permissions and file ownership, etc.), but what does the Repair Permissions app actually do? When are permissions "broken" and how does it know how to "repair" them?

 

[wrldwzrd89]

I've never had to Repair Permissions on my iBook, though I probably should just to make sure everything's clean.

I know a good amount of UNIX (so I understand permissions and file ownership, etc.), but what does the Repair Permissions app actually do? When are permissions "broken" and how does it know how to "repair" them?

Permissions are repaired according to the information stored in the BOM (Bill of Materials) for each installation using Apple's Installer that has a receipt in the Receipts folder. If the BOM and the actual permissions do not match, the Repair Permissions utility changes the actual permissions to match the BOM.

 

[yellow]

that is correct to a certain point but permissions can get screwed up for no reason, like someone else said when a program/script does chmod it might screw up, etc.

I wont even install anything since the last permission repair and i will still have crap loads of fixes.

There shouldn't be any programs/scripts that chmod your system. And unless you've made it so they run as root (which is just retarded to begin with), they cannot modify your root directories without you entering an admin password.

So, repairing permissions as a maintenance thing is only to make you feel good, nothin more,

EDIT: I must caveat this by adding: Unless you yourself have changed the permissions on certain directories in the root file structure.

 

[wordmunger]

So, repairing permissions as a maintenance thing is only to make you feel good, nothin more,

I don't claim to know much about the technical side of computers, but I do know that using "repair permissions" has fixed actual problems with my computer. When my computer didn't work and repairing permissions fixed it, I felt very good indeed.

 

[stoid]

I don't claim to know much about the technical side of computers, but I do know that using "repair permissions" has fixed actual problems with my computer. When my computer didn't work and repairing permissions fixed it, I felt very good indeed.

Indeed. As I mentioned, it did fix Activity Viewer (and God knows what else) for me. Granted you'd probably consider mine to be an extreme case, but still. I had recently installed the XCode development stuff. Could that have done it?

 

[yellow]

I don't claim to know much about the technical side of computers, but I do know that using "repair permissions" has fixed actual problems with my computer. When my computer didn't work and repairing permissions fixed it, I felt very good indeed.

I think you've misunderstood what I'm saying. I certainly don't dispute that Repair Permissions is necessary, or helpful. What I'm disputing is repairing permissions as a "maintenance" thing. As long as one repairs permissions after running any installer that requires an admin password, be it a system update, or an app install, then there should be no problem. Any application that appears as a disk image that gets mounted on your desktop, which you then drag & drop to copy into your /Applications hierarchy, doesn't create an entry in /Library/Receipts/, therefore, has no effect on permissions.

 

[wordmunger]

I think you've misunderstood what I'm saying. I certainly don't dispute that Repair Permissions is necessary, or helpful. What I'm disputing is repairing permissions as a "maintenance" thing. As long as one repairs permissions after running any installer that requires an admin password, be it a system update, or an app install, then there should be no problem. Any application that appears as a disk image that gets mounted on your desktop, which you then drag & drop to copy into your /Applications hierarchy, doesn't create an entry in /Library/Receipts/, therefore, has no effect on permissions.

Okay, now I see what you're saying. Yeah, I don't repair perms on any kind of regular schedule; just when I start seeing problems. But I do think that people can also avoid problems by doing it regularly -- I'm just too lazy to do it.

 

[tomf87]

I doubt the installation of XCode did this, but it's hard to tell.

I looked at the permissions on /Applications on my installation and you do need an admin password to change permissions on the folder. The default applications within this folder would also require an admin password to change. Any other programs you installed can be changed by your normal user account without additional authentication.

I would check that log file again to see what perms it changed. Did it change things like Mail.app, Preview.app, Safari.app, or any of the iapp programs?

 

[coconn06]

Permissions are repaired according to the information stored in the BOM (Bill of Materials) for each installation using Apple's Installer that has a receipt in the Receipts folder. If the BOM and the actual permissions do not match, the Repair Permissions utility changes the actual permissions to match the BOM.

Okay, that makes a lot of sense. Thanks for the info.

 

[yellow]

I had recently installed the XCode development stuff. Could that have done it?

Installing XCode requires an admin password. As a test, I just removed my XCode installation and reinstalled XCode 1.5 and repaired permissions. As you saw, there are TONS of permissions that get corrected, so it was definitely the XCode installation.

To get a glimpse of what permissions it compares to, use the lsbom command.
On my current system, these are the componants installed by XCode:

yellow% ls -lahF | grep "Aug  6"
drwxrwxr-x    3 root     admin         102 Aug  6 17:37 Apr2004XcodeToolsExtras.pkg/
drwxrwxr-x    3 root     admin         102 Aug  6 17:37 BSDSDK.pkg/
drwxrwxr-x    3 root     admin         102 Aug  6 17:37 CHUD.pkg/
drwxrwxr-x    3 root     admin         102 Aug  6 17:36 DevDocumentation.pkg/
drwxrwxr-x    3 root     admin         102 Aug  6 17:37 DevExamples.pkg/
drwxrwxr-x    3 root     admin         102 Aug  6 17:36 DevSDK.pkg/
drwxrwxr-x    3 root     admin         102 Aug  6 17:36 DeveloperTools.pkg/
drwxrwxr-x    3 root     admin         102 Aug  6 17:36 gcc3.3.pkg/

Here is an example of the permissions comparison soley used by the "DeveloperTools.pkg", you'll have to look for yourself, because there's just too many to list here:

lsbom /Library/Receipts/DeveloperTools.pkg/Contents/Archive.bom

 

[1macker1]

I've had my mac almost 2 years and i've never repaired permission. What does this repair do?

 

[tomf87]

I just noticed an oddity in the forum index. It said 1macker1 had the 15th post this morning at 10:40am. But when I check, yellow had the 15th post at 9:50am. At first, I thought, oh the post must have been deleted. However, if it was it would have been the 16th post, because yellow posted after him/her.

Sorry to go off-topic, but found this rather curious.

Attached are the photos for proof.

 

[yellow]

I noticed that too and figured a Mod had deleted that post.

 

[jared_kipe]

Recently I had to work on an ibook that couldn't connect to the internet, well I tried many things, but only the "repair permissions" worked. And knowing the user I think there is only a 1% chance that she has installed anything that needs a admin password in the last few months when it was running fine. So don't tell me how you only need to do it when you install needing passwords. That should just make you feel good at night.

 

[yellow]

So don't tell me how you only need to do it when you install needing passwords. That should just make you feel good at night.

She's never updated her OS or installed security updates in the last few months? Get as angry and uppity as you like, but that is the reality of the situation. How do you explain that her permissions get changed otherwise? She's changing them via the Finder or CLI?

 

[NusuniAdmin]

She's never updated her OS or installed security updates in the last few months? Get as angry and uppity as you like, but that is the reality of the situation. How do you explain that her permissions get changed otherwise? She's changing them via the Finder or CLI?

A little elf named michael jackson changed them....

 

[wrldwzrd89]

There shouldn't be any programs/scripts that chmod your system. And unless you've made it so they run as root (which is just retarded to begin with), they cannot modify your root directories without you entering an admin password.

So, repairing permissions as a maintenance thing is only to make you feel good, nothin more,

EDIT: I must caveat this by adding: Unless you yourself have changed the permissions on certain directories in the root file structure.

Here's an example of how an innocent chmod command run as part of an install could go horribly wrong:
First thing the install script does is drop a file in /Applications (succeeds, no error). Then it changes to /dump (which doesn't exist, so an error is returned - but the script fails to catch it). Thinking it's in /dump now, it copies several other files (which end up in /Applications instead), then it chmod's everything to 777 (still thinking it's in the /dump directory). After that it exits.

 

[tomf87]

Here's an example of how an innocent chmod command run as part of an install could go horribly wrong:
First thing the install script does is drop a file in /Applications (succeeds, no error). Then it changes to /dump (which doesn't exist, so an error is returned - but the script fails to catch it). Thinking it's in /dump now, it copies several other files (which end up in /Applications instead), then it chmod's everything to 777 (still thinking it's in the /dump directory). After that it exits.

Keep in mind, though, that the default applications and the /Applications folder are under by root:admin, so a normal user could not change those perms without sudo and entering a password. They would only change permissions of items the user has write access to.

 

[wrldwzrd89]

Keep in mind, though, that the default applications and the /Applications folder are under by root:admin, so a normal user could not change those perms without sudo and entering a password. They would only change permissions of items the user has write access to.

That's true - however, the exact same situation would still occur if the user was an admin and/or had used sudo, and normal users wouldn't be running these shell scripts anyway.

 

[tomf87]

That's true - however, the exact same situation would still occur if the user was an admin and/or had used sudo, and normal users wouldn't be running these shell scripts anyway.

No user is in the admin unix group by default, so you'd have to edit the /etc/group file manually. I'm not referring to Admin users specified in NetInfo. My user is in the admin group in NetInfo, and I cannot 'chmod 777 /Applications'. I think chmod uses /etc/group instead.

Of course, using sudo removes those barriers, which is what I was saying in my previous post. So a normal user cannot chmod the default apps or the /Applications folder without using sudo.