[Sarc]

I already reported this to Apple, here it goes:

1) In the Leopard File Sharing Pref Pane, added the startup volume (as I sometimes copy non-User-folder files through the network).

2) Noticed that user/group "Everyone" had 'Read' access to most of drive, not just authenticated users.
In the Sharing Pref Pane I couldn't select "No Access" from the menu or remove the user using the 'minus' button, both where greyed out.

(and here comes the big mistake as both options greyed out should have been a pretty clear indication)

3) Deleted the "Everyone" user by pressing the Delete key.

After a reboot the system will hang up on the grey Apple logo with the spinning "gear". When attempting recovery procedures from the install DVD or other bootable disks:
> Disk Utility: reports the disk is fine; when 'Repair Permissions' was attempted it returns a "Underlying task failure" error.
> DiskWarrior: will rebuild the directory, won't be able to repair permissions, system won't be bootable.
> Archive and install from the DVD fails.
> fsck reports all kinds of errors, unreadable sectors and the likes.
> Running 'diskutil repairpermissions' from the Terminal in the Install DVD won't work either, same error as above.
> Data files remain intact and readable from other bootable drives.

Only solution was to zero-out the drive, and reinstall from scratch. Avoided data loss by installing OS X to an external FW drive and used migration assistant with the "From another volume" option, then formatted the internal drive, reinstalled, and used the Migration Assistant the other way round.

Probably could haven been fixed using some Terminal magic, but just couldn't figure what to change.

Hopefully some of you will read this and avoid it. Cheers.

[P]

Hmm. Sounds like something went funny with ACLs. Nasty bug alright. FFR, you might have managed to get it fixed by running fsck and/or diskutil from single user mode. To get to single user mode, boot with Cmd-option-S held down.

[MrNo]

This is a normal behavior.
You don't want to remove Everyone from the root of the drive, as it will make the system useless.
Everyone has to be present for the OS to work properly.
I've had several of my customers do this. All with the same result.
Reinstall the OS was the easiest.

[Cold Warrior]

AFAIK, Everyone does not equal unauthenticated or anonymous users.

[Atheist]

I guess this is the OS X equivalent of dragging your hard drive to the trash?

[tooki]

Well, it should be possible for root to fix it by reassigning correct permissions.

That said... how is this a bug? It seems to me like exactly the right behavior, and Apple took steps to stop you from doing it! You did it anyway, despite the hurdles.

Besides, if you use File Sharing as an admin (that is, log in remotely using an admin account) you automatically see all volumes on the system.

[Atheist]

Originally Posted by tooki 

That said... how is this a bug? It seems to me like exactly the right behavior, and Apple took steps to stop you from doing it! You did it anyway, despite the hurdles.

I would have to disagree. I don't think it should be possible to totally bork your system via the GUI.

[turtle777]

Originally Posted by tooki 

That said... how is this a bug? It seems to me like exactly the right behavior, and Apple took steps to stop you from doing it! You did it anyway, despite the hurdles.

How that ? Does a message pop up, saying "Removing Everyone read-access will wipe your your system" ?

If not, I'd call this a bug. No user should be able to just remove something in the Finder, which causes a complete destruction of the OS.

As MrNo said, security conscious people that are naive might just try this because they are afraid that read-access for Everyone means what it seems to mean on the surface.

-t

[Person Man]

Originally Posted by turtle777 

If not, I'd call this a bug. No user should be able to just remove something in the Finder, which causes a complete destruction of the OS.

But it doesn't cause "complete destruction of the OS," and the system doesn't normally let you do this. The OP had to circumvent the usual protections to do this.

But nothing is destroyed. It doesn't "wipe your system." The permissions of the drive are simply changed. Reset them to normal (which could be accomplished by booting off the DVD and using Terminal, as outlined in this thread. In fact, what is documented in that thread is exactly what happened here.

I will agree with you that the system could throw up a warning that this would be a stupid thing to do and explain why, but this is NOT a bug. Just a poorly designed feature.

[Person Man]

Originally Posted by P 

Hmm. Sounds like something went funny with ACLs. Nasty bug alright. FFR, you might have managed to get it fixed by running fsck and/or diskutil from single user mode. To get to single user mode, boot with Cmd-option-S held down.

Nothing to do with ACLs. Just normal user permissions. And it's not a bug.

[Person Man]

Originally Posted by Atheist 

I guess this is the OS X equivalent of dragging your hard drive to the trash?

No. Nothing is deleted. The permissions of the root volume are changed such that no user, authenticated or not, can read the drive.

If you can reset the permissions, which you can, but it requires the terminal, you don't lose a thing. I know, because the exact same thing happened to me. The difference was that I realized what happened and knew how to fix it. Took me all of 10 minutes.

But that's not going to be true of less technically inclined people.

[turtle777]

Originally Posted by Person Man 

I will agree with you that the system could throw up a warning that this would be a stupid thing to do and explain why, but this is NOT a bug. Just a poorly designed feature.

Ok, semantics.

For most users, this is lethal. Someone who accidentally screws their system doesn't know how to use the Terminal to fix it.

-t

[jmiddel]

Turtle, I totally agree that this is a flaw in the GUI, and that the OP should have gotten a warning. But, re semantics, how about defining a bug as a piece of faulty code, that causes a problem? Here the code worked exactly as intended, but somebody did not realize that people could naively do this without knowing what would happen.

[turtle777]

Originally Posted by jmiddel 

Turtle, I totally agree that this is a flaw in the GUI, and that the OP should have gotten a warning. But, re semantics, how about defining a bug as a piece of faulty code, that causes a problem? Here the code worked exactly as intended, but somebody did not realize that people could naively do this without knowing what would happen.

Ok, that's fine. So it's not a bug.

It's still something Apple should fix. Therefore submitting it as a "bug" is the right thing.

-t

[CharlesS]

Since you're clearly not intended to be able to do this, as the Sharing preference pane greys out the "minus sign" button when Everyone is selected, yet if you press the Delete key instead of pressing the button it works anyway, I'm pretty sure this is a bug. Apple disabled the "minus sign" button to prevent you from being able to do this, but they forgot to disable the Delete key in that case.

[Atheist]

I used to work on a project where the client was obsessive about labeling unintended features of the software as bugs. If the software wasn't behaving as they wanted (even though it was behaving as designed) they insisted it was a bug. We of course told them that any changes to the behavior of the software would be an enhancement, not a bug fix. They settled on calling them "bughancements".

I'll call this a bughancement.

[Person Man]

Still, it's important to accurately describe the behavior in the "bug" report.

The drive is not wiped, nothing is erased, no data is lost.

It's just a simple permissions change on the root volume.

[CharlesS]

Originally Posted by Atheist 

I used to work on a project where the client was obsessive about labeling unintended features of the software as bugs. If the software wasn't behaving as they wanted (even though it was behaving as designed) they insisted it was a bug. We of course told them that any changes to the behavior of the software would be an enhancement, not a bug fix. They settled on calling them "bughancements".

Did you read my post? It's fairly obvious that it is not working as designed, as evidenced by the fact that the button circled in red in this screenshot is greyed out:



Since the button is disabled, it's clear that you're not supposed to be able to delete this. The bug is that even though the button is greyed out, you can circumvent this by pressing the Delete key on the keyboard instead of clicking the button, and get this:



That's obviously a bug.

[Atheist]

Originally Posted by CharlesS 

Did you read my post? It's fairly obvious that it is not working as designed, as evidenced by the fact that the button circled in red in this screenshot is greyed out:

Dude... lighten up. I agree it's a bug as I stated in my first post. The GUI shouldn't let you render your system unusable. I just thought the bughancement thing would add little levity to the discussion.

[Person Man]

Originally Posted by Atheist 

Dude... lighten up. I agree it's a bug as I stated in my first post. The GUI shouldn't let you render your system unusable. I just thought the bughancement thing would add little levity to the discussion.

If you log into the GUI as root, it should let you do it...

[chris v]

The delete key on the keyboard should not be mapped to a grayed-out option. And while the ensuing okay/cancel dialog gives you a chance to re-think, it doesn't explain the consequences.

It should be fixed, and I can see a whole lot of relative newcomers going "Oh Noes! Everyone can access my files! I'd better put a stop to that!"

[0157988944]

It seems that the REAL "bug" here is the total misnomer "Everyone." Because that sounds like it's completely unprotected. It should be "All Users," or something.

[Sarc]

From my point of view, it's a bug in two ways:

1) The Delete key shouldn't allow to do what the rest of the GUI purposefully won't.

2) What I want is to control what "Everyone" can see through the network (that is, nothing at all).
I should be able to specify that I only want my user to read/write the startup volume and no other.

[Big Mac]

Everyone doesn't refer to everyone in the world, as pointed out previously. It refers to every user on the system, and it's safe the way it's set up. If you turn on guest access through the Sharing pane of System Preferences, those connecting would only be able to see the folders you chose to share (usually each user's public folder) and nothing else. You shouldn't go looking to make changes to core parts of the system unless you properly understand what you're doing and why you're doing it.

[barryjaylevine]

How easy it it to hose your user account?

Rename your Home folder. That's it. Next login, all of your info is gone (or, at the very least, in an inaccessible location). The fact that Apple actually permits you to accomplish this renaming without even a warning is, IMHO, a violation of Apple's own Human Interface Guidelines. The user should always be led down the path of least danger.

I'm called in to rectify this situation about a dozen times each year. Most often i can recover the data for the unfortunate soul who has managed to do this bork (as someone else in this thread used the word).

[Hal Itosis]

Originally Posted by Sarc 

When attempting recovery procedures from the install DVD or other bootable disks:
> Disk Utility: reports the disk is fine; when 'Repair Permissions' was attempted it returns a "Underlying task failure" error.
> DiskWarrior: will rebuild the directory, won't be able to repair permissions, system won't be bootable.
> Archive and install from the DVD fails.
> fsck reports all kinds of errors, unreadable sectors and the likes.
> Running 'diskutil repairpermissions' from the Terminal in the Install DVD won't work either, same error as above.
> Data files remain intact and readable from other bootable drives.

Only solution was to zero-out the drive, and reinstall from scratch.

Amazingly drastic consequences for simply tweaking a setting in a file sharing control panel. The fact that "repair permissions" was utterly useless does suggest that ACLs were involved somehow. Disk Utility (rightly or wrongly) does not reset or alter ACLs in any fashion AFAIK... it merely reports interesting anomalies. There is an 'ACL fixer' of sorts, hidden in the Reset Password area (when booted from Leo's DVD).

Originally Posted by Person Man 

Nothing to do with ACLs. Just normal user permissions. And it's not a bug.

You think not? Most of what Leo does under the hood (especially where group "everyone" is concerned) is actually implemented via ACLs. [indeed, they are the heart and soul of "sharing" in OSX 10.5] What you're suggesting is -- that in order to achieve 'unreadability' for everyone -- that the OS went through all associated items and POSIXically did a chmod a-r on them. [?] I sorta doubt it... but that would be quite insane, if true.

[iPublius]

Originally Posted by barryjaylevine 

How easy it it to hose your user account?

Rename your Home folder. That's it. Next login, all of your info is gone (or, at the very least, in an inaccessible location). The fact that Apple actually permits you to accomplish this renaming without even a warning is, IMHO, a violation of Apple's own Human Interface Guidelines. The user should always be led down the path of least danger.

I'm called in to rectify this situation about a dozen times each year. Most often i can recover the data for the unfortunate soul who has managed to do this bork (as someone else in this thread used the word).

I thought Leopard stopped allowing users to do that. No?

[Spheric Harlot]

Originally Posted by barryjaylevine 

How easy it it to hose your user account?

Rename your Home folder. That's it. Next login, all of your info is gone (or, at the very least, in an inaccessible location). The fact that Apple actually permits you to accomplish this renaming without even a warning is, IMHO, a violation of Apple's own Human Interface Guidelines. The user should always be led down the path of least danger.

I'm called in to rectify this situation about a dozen times each year. Most often i can recover the data for the unfortunate soul who has managed to do this bork (as someone else in this thread used the word).

This problem has been fixed since October 29, 2007: Leopard no longer allows you to rename your home folder.

[besson3c]

Originally Posted by Person Man 

But it doesn't cause "complete destruction of the OS," and the system doesn't normally let you do this. The OP had to circumvent the usual protections to do this.

But nothing is destroyed. It doesn't "wipe your system." The permissions of the drive are simply changed. Reset them to normal (which could be accomplished by booting off the DVD and using Terminal, as outlined in this thread. In fact, what is documented in that thread is exactly what happened here.

I will agree with you that the system could throw up a warning that this would be a stupid thing to do and explain why, but this is NOT a bug. Just a poorly designed feature.

And a usability nightmare.

[besson3c]

Software design mantra: "if you give your users a gun, they will shoot themselves with it". This is way too big of a gun to provide users. There is no need to go ahead with such a drastic, sweeping change via this mickey mouse GUI. It accomplishes nothing productive, and so therefore should not be permitted. I think Charles is right that Apple never intended users to be able to do this, the delete key overriding the GUI feedback that the item is not deleteable is indeed a bug. Bugs are reproducable anomalies that do not work as originally designed. It is clear from Charles' observations that this was not what Apple had originally designed, rightfully so.

[Person Man]

Originally Posted by Hal Itosis 

You think not? Most of what Leo does under the hood (especially where group "everyone" is concerned) is actually implemented via ACLs. [indeed, they are the heart and soul of "sharing" in OSX 10.5] What you're suggesting is -- that in order to achieve 'unreadability' for everyone -- that the OS went through all associated items and POSIXically did a chmod a-r on them. [?] I sorta doubt it... but that would be quite insane, if true.

No. It did nothing of the sort. What it did was "chmod a-r /" only.

It did not touch ACLs. It did not touch any other file. Only the root volume's permissions were changed.

I know this because I did the same thing the OP did in the same fashion. On Leopard.

I fixed it by booting off the Leopard DVD, running terminal and doing a "chmod a+r /" on the volume. Voila! Problem solved! Machine booted again.

Before you insist that you are right and I'm not, I suggest you try it yourself. Back up your drive. Go to sharing and do what the OP did. Then fix it like I did.

[Hal Itosis]

Originally Posted by Person Man 

No. It did nothing of the sort. What it did was "chmod a-r /" only.
It did not touch ACLs. It did not touch any other file.
Only the root volume's permissions were changed..

Okay, you are right and i was wrong.

Well, mostly. ACLs were not utilized as i expected, true... but the change seems to be chmod o-rwx
The owner (root) and group (admin) read bits are not affected (nor are their write or execute).
EDIT: oh wait... sharing also killed the sticky bit. Why did it do that? Sticky = good.

# BEFORE:
ls -lde /
drwxrwxr-t@ 36 root admin 1292 Jan 3 16:28 /
# AFTER:
ls -lde /
drwxrwx---@ 36 root admin 1292 Jan 3 16:28 /

So mine went from 1775 to 770. (not 1331)

"everyone" is wrong (especially Leopard)

My confused assumption was assisted by Apple's overloaded use of the word "everyone".
everyone is an actual group with some strange qualities. It has an actual name and gid:

dscl . -read /Groups/everyone PrimaryGroupID
PrimaryGroupID: 12

...but you won't find that group on any file's POSIX listing. And unlike wheel (for example),
it has no "members":

dscl . -read /Groups/wheel GroupMembership
GroupMembership: root
dscl . -read /Groups/everyone GroupMembership
No such key: GroupMembership
dscl . -read /Groups/everyone Comment
Comment: Group membership calculated by system

Yet... group everyone does exist, and can be seen in ACL listings:

ls -lde ~/Music
drwx------+ 25 halito halito 850 Nov 28 00:14 /Users/halito/Music
0: group:everyone deny delete

And if you don't think it works... just try deleting or renaming your Music folder (or any other so protected).

My point here is that, the Sharing Control Panel (and even Finder's Get Info windows) use that same word "everyone" -- when what they really mean is world or OTHERS. OTOH, when the "everyone deny delete" ACL takes effect, it means all users -- even the owner.

Originally Posted by Person Man 

I fixed it by booting off the Leopard DVD, running terminal and doing a "chmod a+r /" on the volume. Voila! Problem solved! Machine booted again.

Folks can save the 5 minutes it takes to boot off the DVD and get an actual Terminal prompt by just going into single-user mode and doing the same thing (don't forget to mount -uw / first).

EDIT: though, i have to ask: if you only did chmod a+r, then what are your perms now?
chmod a+r wouldn't set the execute bit on others (or the sticky bit either)... so maybe your perms are: drwxrwxr-- then???
Anyway, i'm thinking that chmod 1775 / is what i would recommend... to be sure things get back to normal.

:
:

But this brings me to my 2nd beef:

Originally Posted by Sarc 

when 'Repair Permissions' was attempted it returns a "Underlying task failure" error.

Why is Disk Utility on the DVD so dumb? It can't fix the perms on our HD from 770 to 1775?!?!?!
I mean, we command-line junkies can go straight to a terminal... but most users will not be so inclined.
They will probably depend on Disk Utility to repair that one basic permission... and meet with EPIC FAIL.

Unbelievable. That "Underlying task failure" error belongs on the bug list in this thread as well.
[it was also D.U.'s inability to fix a simple permission that led me to suspect ACL involvement.]

[Hal Itosis]

delete dupe

[tooki]

Originally Posted by Hal Itosis 

The fact that "repair permissions" was utterly useless does suggest that ACLs were involved somehow.

No, it doesn't.

There's a huge disconnect between what people think Repair Permissions does (magic; cure-all; knowing, checking, and repairing permissions on every file and folder on the system), and what it actually does (looks at installer receipts and verifies whether those installed packages still have the right permissions, and fixes if necessary). In other words, Repair Permissions ONLY fixes permissions for items that were installed via Installer.app (including Software Update) AND left a receipt. Anything for which there is no receipt will not be checked nor repaired, because the receipts are the ONLY source for permissions data. There's no receipt for your hard disk's root, because that's got nothing to do with a software install.

In fact, Repair Permissions is something that seldom fixes things, because permissions are seldom the source of problems -- people just love to use it because it's there.

[tooki]

Originally Posted by Hal Itosis 

But this brings me to my 2nd beef:

Why is Disk Utility on the DVD so dumb? It can't fix the perms on our HD from 770 to 1775?!?!?!
I mean, we command-line junkies can go straight to a terminal... but most users will not be so inclined.
They will probably depend on Disk Utility to repair that one basic permission... and meet with EPIC FAIL.

Unbelievable. That "Underlying task failure" error belongs on the bug list in this thread as well.
[it was also D.U.'s inability to fix a simple permission that led me to suspect ACL involvement.]

You can reach that conclusion only by not understanding what the Repair Permissions function is: a tool to check the permissions of software installed via Installer.app. Despite its name, it is not a generic permissions tool, it's designed only to operate in a small, specific scope.

It probably Epic Fails because the Repair Permissions tool has no permission (although if booted from DVD, it should have full root access) to go read the receipts folder (on the disk to be repaired) that it relies on as its sole source of permissions data. If there's no receipt instructing Repair Permissions what to do with a particular file or folder, then the file or folder will not be inspected or corrected, regardless of the consequences or circumstances.

(On Panther and earlier, Repair Permissions had to be run from the disk being repaired, because it only looked at the Receipts folder on the current boot disk, so if you booted from the DVD, it had only minimal receipts to look at -- none of the ones for your apps would be present, for example. On Tiger [IIRC] and Leopard, Repair Permissions can now be run successfully from the DVD, because the tool now uses the Receipts folder from the disk being repaired, regardless of what the boot disk is.)

Someone using POSIX permissions or ACLs to remove access from the root of the boot disk is probably not something the designers of Disk Utility anticipated many people doing, so I can see why they might not have bothered to add a check for it. (Or they did think about it, and have a sound reason to avoid it.)

[Hal Itosis]

Originally Posted by tooki 

Anything for which there is no receipt will not be checked nor repaired, because the receipts are the ONLY source for permissions data. There's no receipt for your hard disk's root, because that's got nothing to do with a software install.

As those two sentences are the crux of both your posts, i can simply address them (and ignore silly quips about which one of us thinks they have understanding of permissions vs ACLs).

Code:
$ lsbom -p mMUGsf /Library/Receipts/boms/com.apple.pkg.Essentials.bom |head
41775	drwxrwxr-t 	root	admin		.
40775	drwxrwxr-x 	root	admin		./Applications
100664	-rw-rw-r-- 	root	admin	0	./Applications/.localized
40775	drwxrwxr-x 	root	admin		./Applications/AppleScript
40775	drwxrwxr-x 	root	admin		./Applications/AppleScript/AppleScript Utility.app
40775	drwxrwxr-x 	root	admin		./Applications/AppleScript/AppleScript Utility.app/Contents
100664	-rw-rw-r-- 	root	admin	3372	./Applications/AppleScript/AppleScript Utility.app/Contents/CodeResources
100664	-rw-rw-r-- 	root	admin	1097	./Applications/AppleScript/AppleScript Utility.app/Contents/Info.plist
40775	drwxrwxr-x 	root	admin		./Applications/AppleScript/AppleScript Utility.app/Contents/MacOS
100775	-rwxrwxr-x 	root	admin	78176	./Applications/AppleScript/AppleScript Utility.app/Contents/MacOS/AppleScript Utility

Just guess what that red line above refers to.

Code:
$ pkgutil --file-info /
volume: /
path: .

pkgid: com.apple.pkg.BaseSystem
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363077
uid: 0
gid: 80
mode: 41755

pkgid: com.apple.pkg.Essentials
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363331
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.BootCamp
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363352
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.BSD
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363433
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.iPodSupport
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363443
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.PodcastCapture
pkg-version: 1.0.0.1.1.1192168948
install-time: 1196363447
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.Directory
pkg-version: 1.0.0.1.1.1192168948
install-time: 1196363456
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.JavaToolsLeo
pkg-version: 1.0.0.9000000000.1.1192168948
install-time: 1196363460
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.AdditionalEssentials
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363474
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.AdditionalSpeechVoices
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363696
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.AsianLanguagesSupport
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363706
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.MediaFiles
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363738
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.MigrationAssistant
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363756
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.Mail
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363785
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.AddressBook
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363793
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.iCal
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363804
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.Automator
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363812
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.DVDPlayer
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363818
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.iTunes
pkg-version: 7.4.2.1.1192168948
install-time: 1196363836
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.iChat
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363847
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.Java
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363876
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.Safari
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363884
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.OxfordDictionaries
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363917
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.BrotherPrinterDrivers
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196363985
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.CanonPrinterDrivers
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196364053
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.EpsonPrinterDrivers
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196364290
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.HewlettPackardPrinterDrivers
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196364435
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.LexmarkPrinterDrivers
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196364493
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.XeroxPrinterDrivers
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196364642
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.SamsungPrinterDrivers
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196364663
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.MacOSX.lang.sv
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196364687
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.X11User
pkg-version: 10.5.0.1.1.1192168948
install-time: 1196364713
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.update.os.10.5.1
pkg-version: 1.0.1.1191932192
install-time: 1196374137
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.MacBookMacBookProKbdSU
pkg-version: 1.1.1.1191419069
install-time: 1198050506
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.update.security.2007.009
pkg-version: 1.1.1.1191932192
install-time: 1198366461
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.update.os.10.5.2.combo
pkg-version: 1.0.1.1191932192
install-time: 1202790807
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.update.os.LeopardGraphicsUpdate.1.0
pkg-version: 1.0.1.1191932192
install-time: 1202791585
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.BuiltInKybdFirmwareUpdate
pkg-version: 1.0.1.1202757645
install-time: 1203493673
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.Safari31UpdLeo
pkg-version: 3.1.0.1.1191932192
install-time: 1205855824
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.update.security.2008.002
pkg-version: 1.0.1.1191932192
install-time: 1205877419
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.Time-Machine-Update
pkg-version: 1.0.1.1191932192
install-time: 1205991576
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.Safari311UpdLeo
pkg-version: 3.1.1.1.1191932192
install-time: 1208458525
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.JavaSE6
pkg-version: 10.5.0.1.1.1192168948
install-time: 1209608837
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.update.os.10.5.3.combo
pkg-version: 1.0.1.1191932192
install-time: 1212023877
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.update.os.10.5.4.combo
pkg-version: 1.0.1.1191932192
install-time: 1220481452
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.update.security.2008.005
pkg-version: 1.0.1.1191932192
install-time: 1220485486
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.update.os.10.5.5.combo
pkg-version: 1.0.1.1191932192
install-time: 1221531856
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.JavaForMacOSX10.5Update2
pkg-version: 10.5.0.1.1.1192168948
install-time: 1222349229
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.update.security.2008.007
pkg-version: 1.0.1.1191932192
install-time: 1223615452
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.AirPortExtremeUpdate2008004
pkg-version: 1.0.1.1188305148
install-time: 1226300713
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.Safari32Leo
pkg-version: 1.0.1.1191932192
install-time: 1226633753
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.Safari321Leo
pkg-version: 1.0.1.1191932192
install-time: 1227612616
uid: 0
gid: 80
mode: 41775

pkgid: com.apple.pkg.update.os.10.5.6.combo
pkg-version: 1.0.1.1191932192
install-time: 1229405632
uid: 0
gid: 80
mode: 41775

Just guess what those 50+ red lines above refer to.


--


BUT -- even if you were right, and there was no specific entry for "/" in any reciept -- that situation would *still* be inexcusable... and not worthy of the effort you put into those two posts. For Disk Utility to be so helpless in the face of one bit changed on the read permission for "others" on an HD -- and crap out immediately -- is just a joke.

[tooki]

The issue here isn't ACL versus POSIX permissions (I understand both just fine). I wasn't insinuating that you don't understand permissions -- I was insinuating that you may not be fully clear on what Repair Permissions does and does not do.

The issue here is that the receipt in question is being read (or rather, attempting to be read) from the disk being repaired, so if Disk Util can't read the receipt, it can't see what permissions it should be setting to.

That said, I don't necessarily disagree with you that Disk Util shouldn't be able to fix -- or at least identify -- the problem.

[turtle777]

Originally Posted by tooki 

The issue here is that the receipt in question is being read (or rather, attempting to be read) from the disk being repaired, so if Disk Util can't read the receipt, it can't see what permissions it should be setting to.

If that's the case, shouldn't DI automatically restore the access rights to the receipts folder ?

I'd say this is something Apple should "fix".

-t

[Person Man]

Originally Posted by turtle777 

If that's the case, shouldn't DI automatically restore the access rights to the receipts folder ?

I'd say this is something Apple should "fix".

-t

The issue is not the permissions on the Receipts folder. It's that it doesn't have permission to read the entire disk at all, in this case. It should be fixed, yes.

[Person Man]

Originally Posted by Hal Itosis 

# BEFORE:
ls -lde /
drwxrwxr-t@ 36 root admin 1292 Jan 3 16:28 /
# AFTER:
ls -lde /
drwxrwx---@ 36 root admin 1292 Jan 3 16:28 /
[/tt]
So mine went from 1775 to 770. (not 1331)

EDIT: though, i have to ask: if you only did chmod a+r, then what are your perms now?
chmod a+r wouldn't set the execute bit on others (or the sticky bit either)... so maybe your perms are: drwxrwxr-- then???
Anyway, i'm thinking that chmod 1775 / is what i would recommend... to be sure things get back to normal.

You are correct. My permissions are 1775 now. I didn't actually issue the command listed above. I just used the permissions for the root drive on my MacBook Pro as a model for the permissions on my Power Mac G5. Worked fine... everything was (and is) back to normal.