What's With Leopard Permission Repair?

SINC

Ever since I left Tiger behind, permission repairs have sucked. I tired again tonight and when I saw, "estimated time less than one minute" I had hope.

Eight and one half minutes later, I got this on my brand new MBP:

Repairing permissions for “Macintosh HD”
Warning: SUID file "usr/libexec/load_hdi" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/DiskManagement.framework/Versions/A/Resources/DiskManagementTool" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Resources/Locum" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/Install.framework/Versions/A/Resources/runner" has been modified and will not be repaired.
Permissions differ on "private/var/log/secure.log", should be -rw------- , they are -rw-r----- .
Warning: SUID file "System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/readconfig" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/writeconfig" has been modified and will not be repaired.
Warning: SUID file "usr/libexec/authopen" has been modified and will not be repaired.
Warning: SUID file "System/Library/CoreServices/Finder.app/Contents/Resources/OwnerGroupTool" has been modified and will not be repaired.
Warning: SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" has been modified and will not be repaired.

Permissions repair complete

When will Apple do something about this now useless and aggravating feature in Leopard?

__________________
Visit my website: St. Albert's Place

"When the chips are down, the buffalo is empty."
Never squat with your spurs on.

Cole Slaw

I get the same thing when I repair permissions in Leopard.
It just seems to go on forever compared to how it worked in Tiger.

__________________
24" 2.4 Aluminum iMac, 1 TB HD, 4g RAM
32 gig iPhone 4

Jeepdude

For some reason, it takes forever.

There were a few threads in the Apple discussion forums on this. They suggested reinstalling 10.5.1 update via download/install (as opposed to software update).

EDIT: An Apple Tech Note talks about this, but only says these messages can be safely ignored.

For me it cleared out all those error messages, but the detect/repair still takes a while.

I'm on a MBP 2.16, 3GB ram...

__________________
15" MacBook Pro Core2Duo 2.4
24" iMac Core 2 Duo
30GB iPod Video
2nd Gen Shuffle
PC in pieces under my bed.

Orion

I've read the same as what Jeepdude mentioned (download and install) and that's how I updated.

So far as I can guess it seems that Apple has to figure out just how the new Access Control Lists will be handled by Disk Util. Actual permission repairs seem reasonably swift once they start. DU may be comparing the ACLs with the Unix permissions which seems to take time.

This is all my opinion / guessing. No proof.

GratuitousApplesauce

OK, I'm waaaaaaaaaaay out of my depth here and I seem to be having some very annoying problems with permissions under Leopard.

I was trying to move some of my music files around within my /Users/(myStandard-nonAdminUser)/Music folder and migrate a bunch of backlogged .mp3s into my iTunes folder Music/iTunes/iTunes Music folder. I discovered that to move them or change the names of any of the folders and files - many of which I had created - I was being prompted for my admin password. In some cases even the admin pass wouldn't allow me to change the names.

So I tried fixing the permissions from within the Get Info window. No effect. What I saw on the Get Info window of the affected files was a note under Sharing & Permissions reading "You have custom access" instead of the usual "You can read and write".

I knew enough about using the Terminal to be able to look at files in there and view the exact permissions. The affected ones were -rwx---rwx+ or -rwx---rwx@.

I started looking around the web for how to fix this and found a page on the macosxhints forum, where some quite knowledgeable people mention how Apple has introduced ACLs (Access Control Lists) into Leopard. Permissions Nightmare With Leopard

This is starting to look like a nightmare to me.

I followed the advice of the final post in the thread which recommended using the command chmod -R -a# 0 to eliminate the ACLs attached to the permissions. I did not apply this to my whole home folder as was recommended, but just applied it to a few directories within the Music folder to see if it would work. It seemed to be working OK, but the first thing I discovered was that it was going to be tedious. The change doesn't seem to propagate downwards through many or all directories. I tried applying it up the directory chain a bit but it didn't seem to work in that case either.

So far, this seemed somewhat annoying until I realized that this permission problem is through files all over my home folder and Documents folder. Now I'm really annoyed. I tried making changes to the names of graphics files, spreadsheet and text files throughout the folder and found that I couldn't do this or put them in the trash without an admin password. In some cases the admin pass wasn't enough and in one case I found that even using my root password didn't do it. Now I'm more than really annoyed.

At this point I'm looking at a huge amount of work to downgrade to Tiger or methodically go through a ton of files using chmod.

I'm not sure what to do at this point since I don't really know what's going on and I don't want to make anything worse. This could be a case where a little bit of knowledge is a dangerous thing, although I was being quite conservative about any of the Terminal changes I made. From what I'm reading on the web about this it looks like Apple has really dropped the ball with their permissions implementation in Leopard.

Anyone have any ideas?

Is this what it's like in the land of MS Windows?

MacDoc

You'll notice that several utilities, SuperDuper, iDefrag, Onyx etc are not yet up to Leopard support.

There are clearly still some issues in handling the changes in the deep file structure.

__________________
Are you backed up??? if not why not? - Superduper is FREE!!
Find out more here
Support Green- buy Bullfrog Power http://www.bullfrogpower.com/

chas_m

Permissions repair under Leopard does not take noticeably longer (though I'm sure it's slightly longer) than it did in Tiger.

I did an A&I which cleaned up my "highly tweaked" system nicely, maybe that's the reason -- I don't know.

This thread got me curious so I decided to time the repair just now: 1 min, 10 seconds. Seems a bit slower than Tiger but nothing to write home about ...

__________________
Cheers
chas_m

Evangelist, ACDSee Pro for Mac: Get the beta! Join the community!
Help us build the next great Mac photo manager!

Our life in Victoria BC • Music blog • My Podcast • Film blog
Victoria Macintosh Users Group

biovizier

There could be more than one cause for this. For one, there appears to be a bug in how permissions work in Leopard (i.e. they don't work as it is supposed to), affecting both the "Finder" and unix layer. Another possible issue is ACLs - in Leopard, users' "home" folders and most of their standard "top level" folders ("Desktop", "Documents", etc.) have the "group: everyone deny delete" rule that prevents deletion and moving (renaming counts as removing) of any items with that ACE. The problem is that the stupid new "Get Info" interface does not show this rule, yet allows a user to apply it to "enclosed items". So a user might make an intentional change to the permissions on eg. the "Music" folder to allow someone else access, then use "apply to enclosed items", not realizing that they are also transferring the ACLs at the same time. Then, since "Get Info" doesn't even display negative ACEs, the user can't get rid of it (or even know that they are there) without going to the command line.

The command 'chmod -R -a# 0...' just removes the first rule of the named item. If there is more than one rule, the former rule #1 becomes rule #0 (and so on) and the command would have to be repeated until all rules are gone. And as you noted, the command only acts on the named item but not on any contents if the item is a directory.

Assuming you own all of the files, all ACLs on a folder and it's contents can be stripped using:Note that this may not be what you want since an ACE is used when access rights to some user are granted using "Get Info" - that would be stripped as well. But you could just add those back (and use "apply to enclosed items" at that point). After doing all that, if the folder being worked on is the "home" or one of the "standard" folders, it might not be a bad idea to put the original ACE back as well, which was probably intended to prevent the user from accidentally deleting eg. their whole "Documents" folder (something a poorly designed "column view" increases the possibility of). i.e.

hayesk

Here's an idea. STOP repairing permissions. Seriously - this is such a troubleshooting red herring it's not funny. Back in MacOS 9 and earlier it was "rebuild your desktop" and "zap your PRAM". Now it's repair permissions.

What do you think will happen to your Mac if your secure.log has permission -rw-r----- and not -rw-------?

If you do not know the answer, then stop worrying about permissions.

Lars

Excellent post!

__________________
Apple Certified Technician ACMT|ACHDS 10.3-thru-10.5|10.6+
Mac mini (Early 2009) 2.0GHz|4GB|500GB|NVIDIA Geforce 9400M|AP|BT|Mac OS X 10.6.4
Sound System Audio Engine A2 2.0.
iPhone: 3GS 16GB