Disc Utility always set wrong permissions of the startup disc

Question

The permissions of the startup disc should be "drwxrwxr-t 39 root admin", right?
But everytime I repair my permissions with disc utility I get the (german) message:
Benutzer unterscheidet sich für ., Soll-Wert: 501, Ist-Wert: 0
Die Gruppe unterscheidet sich für ., Soll-Wert: 501, Ist-Wert: 80.
Die Zugriffsrechte unterscheiden sich für ., Soll-Wert: drwxr-xr-x , Ist-Wert: drwxrwxr-t .
And the permissions of the startup disc are set to:
drwxr-xr-x 39 Nomis101 Nomis101
(I've read that out with "$ ls -ld /")
Than I "repair" the permissions with "$ chmod 1775 /". And next time I use disc utility I have the same again.
I've repaired the permissions in single user mode, I've booted from the install DVD and reseted my ACLs, I've removed my ACLs. But nothing seems to help.
Sometimes I also have the issue that I cannot move any file on my desktop anymore or that I have suddenly no write permissions in the folder /Volumes/Macintosh HD
I suspect MacPorts 1.7 or Mercurial as the malefactor, because the issues accumulate after I've done something with MacPorts (or Mercurial). But I'am not sure with that.

Answer 1

{quote:title=V.K. wrote in another thread...:}If I'm not mistaken you told me once a while ago how to modify permissions database which seems to be required there.{quote}
Hmm, that's actually a bit of a tough one - Sorry, but I think it's beyond me.
My understanding of the permissions database consists of only what I have been able to piece together from tinkering, and while I have been able to edit individual entries and have "repair permissions" behave as expected with the edits, "/" is a bit different.
Basically, every time something is installed that results in an update to the permissions database, entries are added, i.e. the entry for a file isn't edited but rather a whole new entry is added. That applies to a given file in the update, as well as every folder on the path to that file. Since installations are pretty much all rooted in "/", that means a new entry for "/" is created every time any installer updates the receipt database, and other things may add entries as well -- I have 88 entries for "/" in there on my system. This does't display all of the entries, but a slightly more user-friendly way is to view most of them is to use:<pre>
pkgutil --file-info /</pre>
I haven't dug that deeply, but I don't know what determines which entry will be used during the actual permissions verification / repair operation (it's been a while but I seem to recall that it wasn't as simple a matter as "most recent", for example), so figuring out which one to edit might be a challenge.
And there are cases like "/" where there are entries in the database, but as you pointed out, that seem to be ignored when repairing of verifying permissions, and I have no idea what flags the system to ignore those.
Interestingly, of the 88 entries on my system, 83 call for "1775" permissions, but 5 of them (mostly "Safari" updates but also the "BaseSystem" package) actually say the permissions should be "1755"...
I think for the OP, the bigger issue is trying to figure out (and stopping) whatever it is that keeps wrecking security by changing the ownership to the user...