What's With Leopard Permission Repair?

MacDoc · Dec 6th, 2007, 11:54 AM

Yeah sure ...ignorance is bliss

The ONE time when repairing permissions is a useful exercise is when there a upgrades and installs going on and I can guarantee that's the case with Leopard adopters.

a sensible response to another "repairing permissions is meaningless": post.

	Quote:
	Actually, as an IT, here's the real question. Does Repair Permissions ever break anything? As far as I know, the answer is no. Do things get fscked up by various installers, apps, god-only-knows-what over time? Yes. So adding repair permissions to your laundry list of stuff to try is simple, takes 60 seconds to try, and doesn't cause more harm then was already present before it happened. Also, it sometimes works. That's basically end of story in my book. It stays on the list.

I concur....sometimes it works and it does no harm.

Case in point

	Quote:
	I actually had a user complain that the WebObjects licence installer would validate the licence key but would then fail, saying "could not write licence file". Rather than pull up the WO5.2\ Installer.pkg/Contents/Archive.bom and grep for the appropriate entry, guess which over-the-iChat solution I proposed to the user? Guess whether it worked? I agree that the generic "I repaired permissions, rebooted, repaired permissions and now my deceased mother has risen again" weenies are being stupid. But don't you DARE go writing the permissions fix off as a waste of time :-P

hayesk · Dec 6th, 2007, 03:29 PM

	Quote:			Originally Posted by MacDoc
	Yeah sure ...ignorance is bliss ... I concur....sometimes it works and it does no harm.

Actually, if you have any application that uses OpenBase in Leopard, it will cause harm. Repair permissions tried to reset openbase-owned files to system owned, causing the DBMS to stop serving its databases.

Your posted case could have been solved by a simple command. And anyone administering WebObjects should be familiar with the command.

File permissions don't spontaneously change - even through upgrades. Repair permissions is good when system files are moved to drives or folders where the permissions are not preserved. It is not a troubleshooting catch-all and people are treating it as such.

So sure, go ahead, repair permissions all you want. I have better things to do with my time.

GratuitousApplesauce · Dec 6th, 2007, 05:01 PM

	Quote:			Originally Posted by 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.

First, many thanks for taking the time to give this advice biovizier. Much appreciated.

From what I'm reading it seems that there has been some unintended blowback from Apple trying to protect the top level folders in the users home folder. This seems like a good idea. When I was first using OS X I almost set in and started changing around those folders to a system of folders I had used under OS9 and earlier, until I just happened to read somewhere that this might not be a really good idea. But I'm sure that Applecare has lots of reports of people screwing up their systems by renaming their Applications folder to "My groovy warez" folder or something.

I think in the case of my Music folder I may have altered all the contents from the Get Info window, applying permissions to all enclosed items, but I think I did that only after I ran into this "custom access" problem on some of the enclosed files, some that I had copied over from my older Mac using an external drive. Since I tried a number of different things, I'm not sure exactly of the sequence of events, but it certainly seems like the info provided in the Get Info window is definitely incomplete.

From what I can tell wherever these ACLs are present, the Get Info window will read under "Permissions & Sharing" "You have custom access" rather than any of the other things we have been used to seeing there.

In the case of my Documents folder, I'm pretty sure I didn't make any permission changes there but somehow these ACLs have shown up there. And within the folder it seems like they appear in a hit or miss fashion as well.

The bulk of the content in the Documents folder (which is pretty large, encompassing graphics, text documents and spreadsheets that I've created since 1994) was all moved over to my G5 from a backup recently. I got this new-to-me G5 PowerMac a bit more than a month ago, installed Leopard on its completely wiped drive and I copied my cloned backup of the HDD from my G4 PowerMac into a partition on one of the G5 internal HDDs. Then I copied the contents of the Documents folder from that backup into the Documents folder of my new Standard non-admin user account.

I wonder if there might be something else in place that causing these permission changes. Some background process run amok? I'm not discounting the possibility that I may have somehow inadvertently made these changes, but generally I'm pretty methodical about screwing around with stuff like permission changes.

	Quote:			Originally Posted by biovizier
	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.

Hmmmm .... OK, I thought it might be working down a few levels but in a seemingly random fashion, but I could be mixed up. I must have misread the macosxhints post that I quoted because I thought that the author of it was saying that this command would propagate downwards.

	Quote:			Originally Posted by biovizier
	Assuming you own all of the files, all ACLs on a folder and it's contents can be stripped using: Code: chmod -RN /path/to/folder 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. Code: chmod +a "everyone deny delete" /path/to/folder

OK, just so that I'm clear that I understand this, I could use

Code:

chmod -RN /path/to/folder

to take all the ACLs off my Music folder for instance as well as all the subfolders and files contained in it? Then I could go back and use

Code:

chmod +a "everyone deny delete" /path/to/folder

to re-establish the ACL to just the Music folder without that going down the directory?

Thanks again, this is a big help.

biovizier · Dec 6th, 2007, 08:36 PM

	Quote:
	OK, just so that I'm clear that I understand this...

That's right. You can read the chmod man page for details, but basically, '-N' removes ACLs, and '-R' makes 'chmod' act on all files inside the named folder so without the '-R', only the actual folder is affected. The ACLs are explained there in detail as well. For some reason, the 'man' page installed by the 10.5 installer on my system is outdated, but the one on the Apple site is correct for the version of 'chmod' installed.
Mac OS X Manual Page For chmod(1)

So for the "Music" folder, assuming it's in the top level of your "home" folder, you own it, and you just want to put things back to the default state (i.e. you aren't trying to give someone else access to it or anything), these two commands should work:

Code:

chmod -RN ~/Music
chmod +a "everyone deny delete" ~/Music

GratuitousApplesauce · Dec 6th, 2007, 10:05 PM

	Quote:			Originally Posted by biovizier
	That's right. You can read the chmod man page for details, but basically, '-N' removes ACLs, and '-R' makes 'chmod' act on all files inside the named folder so without the '-R', only the actual folder is affected. The ACLs are explained there in detail as well. For some reason, the 'man' page installed by the 10.5 installer on my system is outdated, but the one on the Apple site is correct for the version of 'chmod' installed. Mac OS X Manual Page For chmod(1) So for the "Music" folder, assuming it's in the top level of your "home" folder, you own it, and you just want to put things back to the default state (i.e. you aren't trying to give someone else access to it or anything), these two commands should work: Code: chmod -RN ~/Music chmod +a "everyone deny delete" ~/Music

Yep, that command seems to be working fine. I tried it on some lower levels and moved up to higher directories and it all seems to work.

I also made an untitled folder within my home folder and filled it with some TextEdit files and sub-folders, to try out both commands on and they work exactly as advertised.

I've looked at the different man pages both within Terminal and elsewhere but I find that they are sometimes difficult as a non-geek to understand. I usually don't get too much useful info from them. I guess I need the UNIX for dummies version.

Once again, many thanks.

I'm going to be getting some feedback to Apple that they need to improve the handling of permissions on their Get Info windows so people like me can't so easily screw up our systems and then have to plunge into the chilly UNIX water to attempt to fix things.

biovizier · Dec 8th, 2007, 06:03 PM

	Quote:			Originally Posted by GratuitousApplesauce
	I'm going to be getting some feedback to Apple that they need to improve the handling of permissions on their Get Info windows

That's great, and I hope more people do this. And I hope Apple listens because "Get Info" isn't really useful right now...

Getting back to the original question re permissions repair:

	Quote:			Originally Posted by SINC
	When will Apple do something about this now useless and aggravating feature in Leopard?

Actually, the feature is better than it was before in one significant way. Recall that MOAB demonstrated that you could take a setuid executable, replace it with your own evil executable, and run "repair permissions" which would proceed to blindly "repair" the permissions of that file making the evil executable run with "root" privileges. No doubt in response to this embarrassment, a mechanism appears to have been introduced in "Leopard" that makes it possible to designate that a given setuid executable is to be checked (SHA-1 digest) agains a reference value, written to a database at the time the file is installed. However, one of the kinks in the system appears to be that when an update replaces or patches the original version of the SUID executable, the database storing the reference permissions and checksum information is not always updated with the new values (eg. the 10.5.1 stand-alone updater did, but the "patch" did not). So when "repair permissions" is run, it may recognize that the executable's sha1 doesn't match the one in the database, and throws up a warning message.

The database containing this information is "/Library/Receipts/db/a.receiptdb". I haven't been able to figure out how to get the system to force an update, or even how to get it to replace the database if it is removed. However, 'file' identifies the database as a "SQLite database (Version 3)", and Leopard conveniently has added '/usr/bin/sqlite3' to the default install. So if the messages bother you that much, it is possible to manually update individual entries yourself. Or you could just ignore the warnings until Apple smoothes out the bumps in the installation procedure. Ignore the messages, that is, unless you have reason to suspect something actually has illegitimately alterred the executables...

John F · Jan 25th, 2008, 03:42 AM

Permissions is one thing, but I have completely lost administrator access to my Macbook. None of several fixes so far has worked. It may be back to Tiger before the end of the weekend.

John F

jamesB · Jan 25th, 2008, 10:53 AM

	Quote:			Originally Posted by 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.

Onyx claims to be good to go for Leopard wth their "Leopard Only" version.

jb.

bagelmaster · Mar 25th, 2008, 12:13 AM

	Quote:			Originally Posted by biovizier
	That's right. You can read the chmod man page for details, but basically, '-N' removes ACLs, and '-R' makes 'chmod' act on all files inside the named folder so without the '-R', only the actual folder is affected. The ACLs are explained there in detail as well. For some reason, the 'man' page installed by the 10.5 installer on my system is outdated, but the one on the Apple site is correct for the version of 'chmod' installed. Mac OS X Manual Page For chmod(1) So for the "Music" folder, assuming it's in the top level of your "home" folder, you own it, and you just want to put things back to the default state (i.e. you aren't trying to give someone else access to it or anything), these two commands should work: Code: chmod -RN ~/Music chmod +a "everyone deny delete" ~/Music

After upgrading to Leopard could not rename any files or folders for my user account. Running that chmod command did the trick.

Benito · Mar 25th, 2008, 03:38 PM

I am still quite the newbie with Macs, what is Permissions and what does repairing it do for my Mac?

Jan 25th, 2008, 03:42 AM	#17
John F New Neighbour Join Date: Jan 2008 Posts: 1	What's With Leopard Permission Repair? Permissions is one thing, but I have completely lost administrator access to my Macbook. None of several fixes so far has worked. It may be back to Tiger before the end of the weekend. John F

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Leopard versus Frankenmac!	Macaholic	Anything Mac	19	Nov 10th, 2007 02:36 PM
PB 12 with Leopard: can't repair permissions	Pelao	Mac & iPod Help & Troubleshooting	4	Nov 10th, 2007 02:24 PM
Leopard and Filemaker7-9 a non starter + more nasssty	MacDoc	Anything Mac	8	Nov 1st, 2007 02:26 PM
Leopard??..we could not agree more	MacDoc	Anything Mac	12	Oct 18th, 2007 01:15 PM
Leopard Opinion	saxamaphone	Anything Mac	7	Oct 3rd, 2006 11:54 AM

Mar 25th, 2008, 03:38 PM	#20
Benito Full Citizen Join Date: Nov 2007 Location: Toronto Posts: 572	I am still quite the newbie with Macs, what is Permissions and what does repairing it do for my Mac?