Hallo!

Ich habe eine kleine Bitte an euch:

Welche Zugriffsrechte stehen bei euch wenn ihr einen Ordner auf dem Schreibtisch erstellt?

Wenn möglich bitte als Screenshot posten und die Mac OS X Versionsnummer angeben, danke!

Mein System: 10.5.4

Aber mal so: Warum interessiert dich das denn so?

Weil er deine Finger aus'm System nicht lassen kann, er irgendwelche ominösen Bugs finden will und will er sein System unbedingt tot kofigurieren will, damit er nachher wieder sagen kann Apple sei Schuld daran!

seine...

Mac OS 10.5.4

Mr.Kompetent, von 4 auf 5.


Bei mir steht (sauber 5)

Ich
staff
everyone

jo, so ist das

Jaguar1, du liegst falsch!

Das Festplattendienstprogramm auf der Install DVD repariert die Rechte falsch. Bei mir stand als Gruppe wheel und nicht wie es ordnungsgemäß heißen sollte: staff.

Quelle: Apple Discussions und MacOSXHints.ch

Dein Screenshot scheint zu belegen, dass Du ein Upgrade von Tiger auf Leopard gemacht hast. Denn als Gruppenname steht: (unbekannt). Wäre die Migration von Tiger zu Leopard mittels des Migrationsassistenten sauber verlaufen, so stünde dort mit großer Sicherheit: staff.
Vermutung:
Wechselst Du ins Terminal und lässt Dir die Dateirechte desselben Ordners mal mit einem ls -la anzeigen, so zeigt das Dir sowohl Besitzer und Gruppe im Klartext. Und sie sind wahrscheinlich gleich (so war das in Tiger geregelt). Bei Leopard ist das wieder wie bei Panther (und wie bei anderen Unix-Systemen auch). In Leopard gibt es keine Gruppen mehr, die genauso heißen wie der User. Deshalb steht bei Dir dann: (unbekannt).
Eigentlich müsstest/solltest Du das von Hand auf Unix-Ebene nachkorrigieren, weil Apple das bisher nicht bzw. nur unsauber hinbekommen hat.

sierkb:
Das ist soweit richtig.

Nein, das ist gefährlicher Unfug, denn es wäre eine riesige Sicherheitslücke, wenn bei der Migration die Berechtigungen von Hundertausenden von Dateien geändert würden. "staff" ist nur dann die richtige Gruppe, wenn ein Benutzer-Account neu in Leopard angelegt wird und dieser Account neue Dateien anlegt.

Bei Dateien, die "vor" Leopard angelegt wurden, darf auf gar keinen Fall die Berechtigung verändert werden. Aus Sicherheitsgründen müssen bei alten Accounts die Berechtigungen exakt so bleiben wie sie sind. Das würde (vor allem im Netzwerk) sonst im Chaos enden.

Man sollte die Rechte niemals von einer DVD reparieren, sondern immer nur in einem laufenden System.

Auch das zeigt ein großes Missverständnis, denn auf Deine eigenen Dateien greift das Reparaturprogramm nie, überhaupt nie und auf gar keinen Fall zu. Wenn was auf Deinem Schreibtisch liegt, dann kannst nur Du allein entscheiden, welche Berechtigung gesetzt wird. Mac OS X und das Reparaturprogramm dürfen da nicht eingreifen.

Nochmal grundsätzlich:
Es hilft überhaupt nichts, Berechtigungen von privat angelegten Dateien zu vergleichen. Was hier "richtig" ist oder nicht, unterscheidet sich völlig, je nachdem, ob der Benutzer-Account in Cheetah, Puma, Jaguar, Tiger oder Leopard (oder in Netzwerken auf einem ganz anderen Betriebssystem) angelegt wurde, und wie der jeweilige Benutzer seine eigenen Dateien abgesichert hat.

Und noch ein Nachtrag zur Gruppe "(unbekannt)". Das ist lediglich ein Anzeigefehler im Leopard-Finder. Um die Berechtigung korrekt anzeigen zu lassen, musst Du ein anderes Programm verwenden.

osxnerd:

Es geht nicht darum, die Berechtigungen von *allen* Dateien des Systems zu überprüfen und ggf. zu ändern, sondern nur von ganz bestimmten und ausgesuchten. Und dazu gehören meiner Erinnerung nach die betroffenen Dateien und Ordner unterhalb von /Users und im Verzeichnis, wo temporäre Dateien angelegt werden, nämlich /var/folders, wo jeder Benutzer seinen eigenen Ordner hat, dessen Unterordner mit den für diesen Nutzer geeigneten Rechten versehen ist. Dateien und Ordner, die der Gruppe wheel zugeordnet sind, sind hier außerhalb der Diskussion weil nicht betroffen.

> "staff" ist nur dann die richtige Gruppe, wenn ein Benutzer-Account neu in Leopard angelegt wird und dieser Account neue Dateien > anlegt.

Ach, und warum nur für neue Nutzer? Was unterscheidet "neue" Nutzer rein rechtemäßig von etablierten Nutzern? Vom Betriebssystem aus betrachtet: rein gar nichts. Sie haben im Grunde alle dieselben (eingeschränkten) Rechte.
Seit Leopard herrscht da Tohuwabohu, richtig, weil Apple es verabsäumt hat, dem Migrationsassistenten mitzuteilen, dass der den bisherigen Nutzern auch gleich die neuen Nutzer (nämlich staff) beibringen soll. Und deswegen gehören eben standardmäßig unter Leopard nur eben alle neuen Nutzer (mit Nicht-Admin-Rechten) zur Gruppe "staff", die bisherigen Nutzer (mit Nicht-Admin-Rechten) behalten ihre bisherige Gruppenzugehörigkeit, obwohl die im System eigentlich gar nicht mehr verankert ist (und deswegen das System/der Finder) diese auch nicht bis zur letzten Konsequenz zuordnen kann (unbekannt).

Ansatzweise siehe auch

Wer sagt das? Zusammen mit dem Apple Bug Support, mit dem ich über Wochen ein Problem bei mir erörtert habe, welches ursächlich anscheinend genau damit zusammenhing und erst gefixt war, nachdem ich händisch im Terminal die Gruppenzugehörigkeiten gerichtet hatte, sind wir zu einem anderen Ergebnis gekommen.
Ich würde Dir ja gerne den Bug herauskramen (Bug ID# 5901198), den wir da gemeinsam beackert haben, nur leider ist das Bug-System von Apple nicht-öffentlich und damit nicht allgemein zugänglich. ich hatte ein Problem, dass temporäre Font Cache-Dateien vom System nicht mehr richtig gelöscht werden konnten und dadurch regelmäßig und reproduzierbar im Papierkorb meines Hauptnutzers landeten. Ich konnte das Problem letztendlich beheben -- nicht zuletzt aufgrunddessen, *weil* ich nach langem hin- und her und ergebnislosem Ausprobieren und Nachforschen zusammen mit dem zuständigen Apple Entwickler Hand an die Gruppenzugehörigkeiten unterhalb von /var/folders/MeinTempVerzeichnis gelegt hatte. Und aufgrund des Erfolgs übrigens ohne weiteren Kommentar seitens des Apple Bug Maintainers, der wohl sichtlich erstaunt gewesen sein muss, dass diese von Apple so vermurkste Gruppen-Zugehörigkeits-Geschichte offenbar solche Seiteneffekte haben kann. Jedenfalls hat er mich *nicht* oder mir nahegelegt, das zu unterlassen, obwohl ich mit ihm genau diesen Schritt vorher erörtert hatte. Er sagte sinngemäß nur, dass er nicht daran glaube, dass das wirklich die Ursache für mein Problem war. Aber: doch, genau das war es, das war die Ursache.

Siehe auch und , wo ich Hilfe gesucht (und nicht gefunden) habe, bevor ich mich dem Apple Bug Management zugewendet habe, in dessen Verlauf ich das Problem dann lösen konnte.

Das *ist* teilweise im Netzwerk bereits im Chaos geendet, da gab es wohl schon Beschwerden. Nicht aber, weil man das so gändert hatte, wie von mir angedacht, sondern weil es bis dahin *überhaupt nicht* geändert wurde. Apple hat das in dem einen oder anderen der letzten OSX-Updates anderweitig versucht zu beheben, indem man den Umgang (besonders der des Netzwerk-Managers) mit genau diesen "Karteileichen" (also den nicht weiter benutzten Gruppennamen) verbessert hat. Aber die eigentliche Ursache, also die nicht mehr in Verwendung stehenden Gruppennamen, hat man damit wohl nicht angefasst bzw. anfassen wollen, weil es wohl dann erst recht Chaos bedeutet hätte (gerade für Benutzer, die da weniger Ahnung haben).

Siehe auch





Alles Auswirkungen, weil Apple bei der Migration (bzw. dem Migrationsassistenten) von Tiger auf Leopard schlampig gearbeitet hat.

wer migriert denn? Ich habe damals mein Leopard clean installiert, und hatte trotzdem derartige Fehler.

Also, da läuft was faul im Staate Leopard...

äh in der Schweiz, Sir!

Ja, da auch!

Dann hast Du was Grundsätzliches nicht verstanden. Wenn Deine primäre Gruppenzugehörigkeit geändert würde, müsstest Du nicht nur alle Dateien auf allen Festplatten dieses Computers, sondern auch alle Dateien auf (vielleicht gerade nicht angeschlossenen) externen Festplatten und auf allen (vielleicht gerade nicht verbundenen) File-Servern überprüfen und deren Gruppeneigentümer gegebenenfalls ändern. Der Benutzer hatte in der Vergangenheit ja möglicherweise das Recht, überall Dateien anzulegen.

Dies zu tun, ist einerseits völlig unmöglich und wäre andererseits eine ernste Sicherheitslücke.

Sie werden mit einer anderen primären Gruppenmitgliedschaft angelegt. Apple hat die Vorgehensweise in der Vergangenheit mehrmals geändert.

Es bringt nichts, wenn Du hier Geschichten erzählst, dass viele Apple-Mitarbeiter es auch nicht besser wissen. Das weiß ich selbst.

Ja, und da hat er vermutlich Recht.

Es ist richtig, dass der Leopard-Updater mehrere Fehler hat. Dass was Du ursprünglich beschrieben hast, war allerdings nicht der Fehler. Die korrekte primäre Gruppe für in Tiger angelegte und dann migrierte Benutzer ist nicht "staff".

osxnerd:

Es ist, gelinde gesagt, einfach Schwachsinn, solche Gruppenzugehörigkeiten anzulegen, wie es Tiger gemacht hat: jedem Nutzer eine eigene Gruppe zuzuordnen, die den Namen des Nutzers trägt. Also für den User 'sierk' auch eine eigene Gruppe 'sierk', für den User 'Griguleit' auch eine eigene Gruppe 'Griguleit', für den User 'xyz' auch eine eigene Gruppe 'xyz'. Das wird meines Wissens in der gesamten Unix-Welt nirgends gemacht -- weil völlig unnötig. Apple wollte damit vielleicht mal die Sicherheit erhöhen, hat aber wohl bei Leopard gemerkt (Leopard hat ja nun auch offiziell das UNIX-Siegel), dass das völliger Schwachsinn ist. Deshalb hat man das dann wieder zurückgenommen. Und beim Migrationsassistenten hat man die Leute vergessen, die das bisher verwendet hatten bzw. hat seine Netinfo-Datenbank (wo u.a. auch der Finder drauf zugreift) erst mit einem der letzten Updates (ich meine, es wäre 10.5.3 gewesen) befähigt, überhaupt mit diesen 'Karteileichen' umzugehen.

Warum und wozu? Was unterscheidet einen Benutzer 'abc' von einem Benutzer 'def', wenn beide nicht Admin sein sollen und beide eingeschränkte Rechte haben sollen? Wie machen das seit Jahren andere Unixe? Kann es nicht vielleicht sein, dass Apple mit Leopard in dieser Hinsicht zu der Praxis zurückgekehrt ist, die bei anderen Unices und Linux seit Jahren/Jahrzehnten bereits Gang und Gäbe ist? Einfach deswegen, weil man gemerkt hat, dass der in Tiger eingeschlagene Weg bzgl. der Gruppenzugehörigkeiten weder Vorteile noch sonstirgendwas bringt, sondern höchstens Verwirrung und/oder Probleme?

Ich glaube, Du hast überlesen, dass offenbar genau das die Ursache für meine Probleme war und aufgrund der Änderung der Rechte das Problem seitdem mit einem Mal ein für allemal behoben ist. Und Du hast wohl auch die Links überlesen von den Benutzersn, die auf anderen Feldern als ich ihre Probleme hatten und diese erst in den Griff bekamen, als sie an den Gruppenzugehörigkeiten gerüttelt haben. Wäre dieser Weg prinzipiell der Falsche gewesen, so hätte dieser freundliche Apple Ingenieur mich sicherlich eindringlich vor diesem Schritt gewarnt bzw. hätte mir die Sinnhaftigkeit dessen zu erklären versucht, warum ich als Benutzer 'sierk' weiterhin meine eigene Gruppe 'sierk' haben *müsse* und warum es töricht sei, daran zu rütteln bzw. warum es töricht sei, diesen nun in die Gruppe 'staff' zu verfrachten (obwohl Leopard das bei neu angelegten Nutzern genau das tut -- wie andere Unices und Linux-Distris in ähnlicher Weise übrigens auch). Hat er aber nicht getan.
Und schon im nächsten Update von MacOSX wurde irgendwas am Netinfo-Manager korrigiert, was im Zusammenhang mit diesen bis dato verkorksten Gruppenrechten stand. Zufall?

Da sind wohl gleich mehrere Fehler zusammengekommen. Das, was ich beschrieben habe, ist eine Komponente unter mehreren gewesen.

Insofern richtig, als dass unter Tiger jeder Benutzer seine eigene Gruppe erhalten hatte. Benutzer 'sierk' also die Gruppe 'sierk'
Ein Ordner auf meinem Desktop hatte also auf Unix-Ebene einen chown sierk:sierk. Für einen anderen Benutzer namens 'griguleit' sah das auf meinem System dann so aus: chown griguleit:griguleit.
Und genau das ist seit Leopard nun anders. Das ist nun so, wie das bei anderen Unices (incl. Linux) auch üblich ist und auch bei MacOSX vor Tiger üblich war: alle Benutzer des Systems stehen in einer gemeinsamen Gruppe (und nicht wie bei Tiger, dass jeder Nutzer seine eigene Gruppe bekommt), und diese gemeinsame Gruppe heißt seit Leopard für alle Benutzer des Systems: 'staff'. Benutzer, die noch weitere Rechte haben (z.B. der Administrator, root), stehen darüberhinaus dann noch in einer weiteren Gruppe (z.B. admin).
Das 'unbekannt' im Finder-Dialog rührt daher, dass MacOSX seit Leopard aus irgendeinem Grund eben die alten Gruppenzugehörigkeiten nicht mehr kennen will (eben weil sie seit Leopard zurückgeführt worden sind auf 'staff') und Apple es bisher anscheinend nicht sauber hinbekommen hat, diese alten Gruppenzugehörigkeiten der Netinfo-Datenbank trotzdem noch zur Verfügung zu stellen bzw. bekannt zu halten, obwohl sie vom System her eigentlich weder gebraucht noch sonst irgendwie weiter verwendet werden (denn dass es so ist, zeigt ganz offensichtlich die Tatsache, dass unter Leopard neu angelegte Nutzer nun der Gruppe 'staff' zugeordnet werden und nicht mehr nach Tiger-Art ihre eigene Gruppe gleichen Namens bekommen).

Dass das alles evtl. auch Auswirkungen auf irgendwelche Netzlaufwerke haben kann, das habe ich mit keinem Wort bestritten. Ich sage nur, dass Apple da geschlampt hat und mindestens einmal zuviel mit dem herumexperimentiert hat, was unter Unix seit Jahrzehnten erprobte und sichere Praxis ist. Da hat man zu Tiger-Zeiten einen Geist aus der Flasche geholt, den man mit Leopard wieder hineinzwängen wollte (oder aufgrund der Anforderungen für eine erfolgreiche UNIX-Zertifikation vielleicht sogar musste?). Und das unter Tiger begonnene Experiment ist eben ein wenig schiefgegangen bzw. der Versuch, das Rad in Leopard wieder so zurückzudrehen wie es vorher einmal war (und gängige Unix-Praxis ist), ohne dass Probleme auftauchen und der User was merkt, ist ein wenig außer Kontrolle geraten.

Ja, das weiß ich alles. Du brauchst hier nicht seitenweise Text zu posten, nur um von der ursprünglichen Frage abzulenken.

Nein. Du bringst hier nur Sachen ins Spiel, von der vorher niemand geredet hat und die mit der Fragestellung nichts zu tun haben.

Es dürfte Dir entgangen sein, dass ab Leopard die NetInfo-Technologie nicht mehr verwendet wird und deshalb auch kein NetInfo-Manager vorhanden ist.

Nein, das ist für Benutzer-Accounts, die von Leopard neu angelegt werden, anders. Für Benutzer, die nicht von Leopard angelegt wurden, bleibt es beim alten und das muss auch so sein.

Wie ich oben bereits geschrieben hatte, ist das nur ein Anzeigefehler im Finder. Der Workaround für diesen Fehler ist, den Benutzer sowohl Mitglied der Gruppe (Beispiel) "sierkb" als auch der Gruppe "_sierkb" zu machen.

Wo wir dabei sind... Was passiert, wenn ihr von einem Windowsrechner z.b. eine PSD oder INDD auf den Mac kopiert.. ?

Bei mir sind sie auf dem Mac dann schreibgeschützt und ich muss die Rechte neu vergeben.

osxnerd:

Nein, ich habe anhand eines konkreten Beispiels gezeigt, dass es offensichtlich doch nicht so unproblematisch ist, alles beim alten zu belassen und so wie es Apple nach der Migration hinterlassen hat, nach dem man von Tiger auf Leopard migriert hat.

OK. Sorry. Dann ist NetInfo halt jetzt ersetzt worden durch entsprechende andere Tools rund um Directory Service. Die aber alle vorgeschaltet sind vor die entsprechenden traditionellen Unix-Dateien /etc/groups und /etc/passwd.

Dass es anders ist, das wissen wir. Das musst Du nicht ständig wiederholen.
Die Frage ist: WARUM ist es auf einmal anders? Warum ist es auf einmal wieder so, wie es zu Zeiten vor Tiger war bzw. wie es im Grunde auf anderen Unix-Systemen (incl. Linux) auch üblich ist? Was hat Apple geritten, in Tiger Benutzergruppen einzuführen, die genauso heißen wie der Benutzer selber, also jeder Benutzer im Grunde eine eigene Benutzergruppe hat, deren einziges Mitglied allein er ist? Warum macht man das in Leopard auf einmal wieder rückgängig, wenn's in Tiger angeblich sinnvoll und durchdacht war (und damit auch in Leopard sicher sehr sinnhaft gewesen wäre)? Was soll das Ganze? Ich zum Beispiel will auf meinem System, welches ich von Tiger auf Leopard migriert habe, keine Altlasten von Tiger haben, die bei mir evtl. irgendwas in Unordnung bringen können. Und ich hatte Probleme (Thema Font Cache Problem). Wie auch andere Nutzer offenbar Probleme damit haben, dass unter Leopard plötzlich mit zweierlei Maß gemessen wird, wenn man von Tiger migriert ist. Warum hat es Apple nicht geschafft oder einen Mechanismus geschaffen, der die bestehende Rechtevergabe von Tiger nahtlos in die Rechtevergabe überführt (bzw. zurückführt), die unter Leopard nun angesagt ist (und vor Tiger auch schon angesagt war und auch bei allen anderen Unices weiterhin angesagt ist)?

Nein, das ist eben kein simpler Anzeigefehler im Finder! Das ist ein viel tiefer sitzender Fehler. Die Probleme, die sich daraus ergeben haben, habe ich zu spüren bekommen mit meinem Font-Cache, den mein System beim Hochfahren nicht mehr sauber hat löschen können (und in der Folge dann eben zu mir jedesmal in den Papierkorb verschoben hat), und die haben auch noch viele andere Nutzer zu spüren bekommen. Du musst nur mal ein wenig im Netz recherchieren, ich habe ja den einen oder anderen URL genannt.
Mein Font-Cache-Problem tauchte nicht auf, als ich auf dringendes Bitten des Apple Bug Ingenieurs einen neuen Benutzer angelegt habe, um das Problem dort zu beobachten. Welcher, oh Wunder, standardmäßig der Gruppe "staff" zugeordnet wurde. Das war für mich und für den Apple Ingenieur nach vielen, vielen anderen Versuchen, das Problem einzukreisen, der Startschuss, mal an die Gruppenzugehörigkeit meines bisherigen Haupt-Benutzerkontos ranzugehen. Ich habe sie in "staff" geändert bzw. GUID 20. Sowohl in meinem gesamten Benutzer-Ordner als auch in meinem temporären Verzeichnis unterhalb von /var/folders/xyz, wo z.B. auch temporäre Font-Cache-Dateien abgelegt werden. Und: oh, Wunder, das Problem war mit einem Male verschwunden, nachdem auch dort für meine Dateien die Gruppenzugehörigkeit auf das in Leopard neu verwendete "staff" eingeführt worden ist.

Und wie ich im Netz nachlesen kann, scheinen sich einige andere Probleme, die manche Benutzer seit der Migration von Tiger zu Leopard gehabt haben, auch in Luft aufgelöst zu haben, nachdem sie per Hand die Gruppenzugehörigkeiten in Richtung "staff" geändert haben.

Du sagst es selber: ein Workaround. Das ist aber trotzdem keine saubere Lösung, die das Problem an der Wurzel bekämpft bzw. die eigentliche Ursache beseitigt. Die Gruppe, die unter Tiger angelegt wurde, einfach nachträglich (ich meine, das wurde mit 10.5.3 eingeführt) als versteckte Systemgruppe zu kennzeichnen, und sie auf diese Weise dem System bzw. dem Directory Service doch irgendwie zugänglich zu machen, obwohl sie anderweitig eigentlich gar nicht mehr gebraucht wird bzw. die Gruppe "staff" viel sinnvoller wäre, halte ich für eine Krücke und Notlösung und herumdoktern am Symptom und nicht Beseitigung der eigentlichen Ursache.

Weil es ein Irrweg von Apple war. Aber das hat alles mit der Diskussion nichts zu tun.

Weil zum einen Leopard im Moment noch sehr unausgereift ist, zum anderen, weil die Lösung, die Du Dir vorstellst, im Allgemeinen nicht funktioniert. Wie schon mehrmals erwähnt, ist sie im allgemeinen Fall undurchführbar und kann zu Sicherheitslücken führen.

Es handelt sich hier um zwei verschiedene Fehler. Dass neben dem Leopard-Finder auch der Mechanismus des Leopard-Font-Cache fehlerhaft arbeitet, hat niemand bestritten.

Du hast eben Glück, dass Dein System und Dein Netzwerk so klein sind, dass Du den Font-Cache-Fehler auf diese Weise umgehen kannst. Im allgemeinen Fall ist diese Lösung jedoch nicht praktisch durchführbar. Auf keinen Fall während eines automatischen Updates von Tiger auf Leopard.

Es ist ein Fehler, wenn Systemdienste für einen Benutzer nicht funktionieren, wenn dessen Primärgruppe nicht staff(20) ist. Es ist kein Fehler, wenn die Primärgruppe eines Benutzers nicht staff(20) ist. Sie muss völlig frei vergeben werden können.

Um genau diesen Fehler zu bekämpfen, muss man die Anzeige von Benutzerrechten im Finder anders programmieren. Das ist nichts, was ein Benutzer selbst machen kann. Deshalb ist im Moment nur ein Workaround möglich.

osxnerd:

Immerhin nennst Du das Kind beim Namen.

Doch hat es meiner Meinung nach. Sogar sehr viel.

Das sagt wer? Das gilt prinzipiell? Das gilt wohl eher nur dann, wenn es nicht sauber durchgeführt wird, oder?
Und wenn es gar nicht durchgeführt wird, führt es offenbar zu ganz anderen Problemen...

Sagt wer? Wer sagt denn, dass das Eine (Font-Cache-Problem) nicht ein Folgefehler des Anderen (Gruppenzugehörigkeiten und damit andere Rechtevergaben) war bzw. ist? Zumindest bei mir war das Problem mit einem Schlag behoben, als ich den Font-Cache-Dateien die Gruppe "staff" zugeordnet hatte statt die Gruppe "sierk". Und wenn ich mal so die auftauchenden Problematiken mir anschaue, die man im Netz zu ähnlichen Themen finden kann, so waren diese Probleme alle behoben, nachdem man dort ebenfalls die Gruppenzugehörigkeiten in Richtung "staff" abgepasst hatte. Offenbar scheint da dann wohl doch das Eine mit dem Anderen ursächlich irgendwie in Zusammenhang zu stehen, oder?

Du meinst, dass er (seit MacOSX 10.5.3) versteckte (menschliche) Benutzer anzeigt, währendhingegen er andere, versteckte virtuelle System-Benutzer (z.B. _uucp, _lp, _postfix, _mcxalr, _pcastagent, _pcastserver, _serialnumberd, _devdocs, _sandbox, _mdnsresponder, _ard, _www, _eppc, _cvs, _svn, _mysql, _sshd, _qtss, _cyrus, _mailman, _appserver, _clamav, _amavisd, _jabber, _xgridcontroller) weiterhin brav ausblendet?

Viel Spaß Apple beim tieferen Hineinreiten in das Moloch, welches man sich selber seit Tiger geschaufelt hat.

Bezüglich Finder stellt sich das Problem nicht, wenn hier eine Gruppe verwendet wird, die das System auch vorsieht: staff.
Und das kann der geübte Benutzer mit Unix-Kenntnissen auch selber hinbekommen. Für den Ungeübten wird's kniffelig bzw. er sollte die Finger davon lassen, richtig. Dem hätte Apple aber auch vorbeugen können, in dem man ein Tool geschrieben hätte, welches diese Aufgabe systemweit übernimmt und zwar unter Berücksichtigung aller angeschlossener Netzlaufwerke (falls diese davon betroffen sind). Damit hätte Apple jedoch Farbe bekennen müssen, dass man in Tiger bzw. in der Migration von Tiger auf Leopard etwasganz gründlich verbockt hätte. Und diese Blöße ist man anscheinend nicht bereit sich zu geben. Und deswegen wird's dann klammheimlich unter der Decke seitens Apple irgendwie hingefuddelt. Bloß ja kein Aufhebens machen, damit der User nichts merkt, dass da was schiefgelaufen bzw. von Apple Bockmist gebaut worden ist. Ich habe auf solche Fuddeleien keine Lust. Ich möchte ein sauber und ordentlich konfiguriertes System und keine Experimente und Fuddeleien, die da irgendwas wieder begradigen müssen. Und Apple fuddelt da, was dieses Thema angeht, anstatt Ross und Reiter zu benennen und die eigentliche Ursache sauber so zu revidieren, dass ein konstistenter und einheitlicher Zustand herrscht.
Dann werde ich lieber selber tätig und begradige die Dinge selber. Es ist mir völlig klar, dass das nicht jedem Benutzer zugemutet werden kann und soll, weil ihm möglicherweise die dazu nötigen Unix-Kenntnisse fehlen. Aber dazu haben wir ja eigentlich eine Firma Apple, die das übernehmen sollte bzw. solche Dinge erst gar nicht entstehen lassen soll. Das, was Apple da diesbzgl. macht, ist Schadensbegrenzung (weil sie in Tiger an etwas Bewährtem herumexperimentiert haben, wovon sie lieber hätten die Finger lassen sollen). Aber es ist keine Ursachenbekämpfung im eigentlichen Sinne.