Unsichtbare System Gruppen und Benutzer anzeigen

[FritzS]

Mit welchem Terminal-Befehl kann man unsichtbare (System) Benutzer und Gruppen im Finder und auch in "Systemeinstellungen" / "Benutzer und Gruppen" anzeigen lassen?

Bekommen diese unsichtbaren System-User beim Anlegen eigentlich gleich ein kryptisches Passwort mit erstellt?

Bei meiner BIND named Einrichtung bin ich draufgekommen, dass PathFinder sehr wohl alle versteckten System-Benutzer und Gruppen anzeigt. Was für mich sehr hilfreich war um ggf. auch die Rechte der BIND named Konfig-Dateien wieder ins Lot zu bringen. Ich ziehe da einen gemischten Weg Terminal und Finder/PathFinder vor.

ZB. habe ich bemerkt, dass noch ein MacPorts User im System vorhanden ist, obwohl ich MacPorts schon gelöschte habe.
Außerdem habe ich noch einige "verwaiste" com.apple.launchd.peruser. gefunden.

/private/var/db/launchd.db/com.apple.launchd.peruser.

http://superuser.com/questions/361475/com-apple-launchd-com-apple-launchd-peruser-error

 

[simmac]

Wie bei jedem UNIX-System kannst du die Userliste /etc/passwd anzeigen lassen (also zB

cat /etc/passwd

).
Hinweis:
Die tatsächliche /etc/passwd-Datei wird nur im Single-User Mode angezeigt, ansonsten wird auf die Open Directory zurückgegriffen.

Wozu brauchen diese User ein Passwort? Das verstehe ich jetzt nicht so ganz.

 

[FritzS]

Die Kommandline kenne ich, ich will diese User und Gruppen im Finder und "Systemeinstellungen" / "Benutzer und Gruppen" (so wie im PathFinder) wahlweise angezeigt erhalten.

Wenn diese Systemuser kein Passwort haben, kann man sich mit diesen Systemusern nicht am System anmelden, oder ist das irgendwie gesperrt?
Ich habe mich damit noch nie befasst.

 

[Rastafari]

ich will diese User und Gruppen im Finder und "Systemeinstellungen" / "Benutzer und Gruppen" ... wahlweise angezeigt erhalten.

Das geht nur in den Systemeinstellungen und nur mit den Gruppen.

defaults write com.apple.systempreferences com.apple.preferences.accounts._showallgroups -bool yes
# ... && neu anmelden

Wenn diese Systemuser kein Passwort haben, kann man sich mit diesen Systemusern nicht am System anmelden

Nein, das müssen sie ja auch nie. Was will ein im Hintergrund laufender Daemon ohne Benutzerschnittstelle denn mit einem interaktiven Login?

 

[FritzS]

Danke Rastafari!

Wenn diese Systemuser kein Passwort haben, kann man sich mit diesen Systemusern nicht am System anmelden

Das wusste ich nicht - bin da noch etwas Windows (vor-)geschädigt

Nein, das müssen sie ja auch nie. Was will ein im Hintergrund laufender Daemon ohne Benutzerschnittstelle denn mit einem interaktiven Login?

siehe oben - gilt das für alle UNIXe (LINUX), wenn ein Systemuser kein Passwort besitzt kann er sich nicht anmelden oder bedarf es einem zusätzlichen Flag?
Ob wo oder wie erstellt man dieses Flag, wenn man einen Systemuser selbst händisch anlegen würde?
Wie unterscheidet sich nun ein Systemuser von einem den man über "Systemeinstellungen" / "Benutzer und Gruppen" anlegt? Ich habe nur gesehen, dass die User ID der "normalen User" mit 5.. beginnt.

Was mich verwundert, dass PathFinder alle User und Gruppen anzeigt, wenn man damit die Berechtigungen ansieht oder gar editiert. PathFinder macht dies ähnlich wie es unter Linux graphisch dargestellt wird.

PS: Unter Windows haben alle User ein Passwort (das sollte man keinesfalls vergessen oder damit sorglos umgehen), auch jene unter denen bloß ein Service läuft - zumindest war das bis vor einigen Jahren so und würde mich wundern wenn MS das nun geändert hätte. Man kann sich unter Windows auch mit allen Usern am Rechner anmelden, es sei denn eine Windows Police würde dies verbieten.

 

[Rastafari]

gilt das für alle UNIXe (LINUX)

Entgegen häufiger Behauptungen ist GNU/Linux kein Unix. Nur etwas ziemlich Unix-ähnliches.

wenn ein Systemuser kein Passwort besitzt kann er sich nicht anmelden oder bedarf es einem zusätzlichen Flag?

Kein Passwort, kein Login.
In der Grundeinstellung hat nicht mal 'root' ein Kennwort. (Und es gibt auch keinen vertretbaren Grund, daran was zu ändern.)
Anmerkung dazu:
Ein Kennwort das aus einem "Empty String" besteht ist nicht das gleiche wie "überhaupt kein" Kennwort.

Wie unterscheidet sich nun ein Systemuser von einem den man über "Systemeinstellungen" / "Benutzer und Gruppen" anlegt?

Als "Systembenutzer" bezeichnet man die einheitlich vorgegebenen Konten im reservierten Bereich unterhalb der UID 100.
Darüber wird system- und hostspezifisch "frei" vergeben. Ein NextStep/OS X zB vergibt traditionsgemäss den Bereich von UID 100 bis 500 an reine Netzwerkkonten (serverbasierte Verwaltungseinträge) und die UIDs von 501 aufwärts für die gewöhnlichen, lokalen Benutzerkonten.
(Andere *nixe fangen dafür erst bei 1000 zu zählen an, aber das ist funktional unwichtig.)

Was mich verwundert, dass PathFinder alle User und Gruppen anzeigt, wenn man damit die Berechtigungen ansieht oder gar editiert.

Es ist nicht verboten, auch Dinge von fragwürdigster Nützlichkeit anzuzeigen.

PS: Unter Windows haben alle User ein Passwort

Unsinn. In der nackten "Out of the Box" Konfiguration hat dort *überhaupt kein* Benutzer ein Kennwort gesetzt.

Man kann sich unter Windows auch mit allen Usern am Rechner anmelden

Die Identität eines beliebigen Kontos annehmen kann man in Unixoiden Systemen auch. Dafür braucht es kein interaktives Login.
Und nein, unter Windows können sich nur die Benutzer anmelden, die einen entsprechenden Hive in der Registry besitzen und dort die entsprechenden Berechtigungen gesetzt bekommen haben.

 

[FritzS]

Entgegen häufiger Behauptungen ist GNU/Linux kein Unix. Nur etwas ziemlich Unix-ähnliches.

Hängt das etwa damit zusammen, dass OS X hier einen MicroKernel einsetzt? Sonst wird immer davon geschrieben, dass Mac OS X von BSD abstammt.

Kein Passwort, kein Login.
In der Grundeinstellung hat nicht mal 'root' ein Kennwort. (Und es gibt auch keinen vertretbaren Grund, daran was zu ändern.)
Anmerkung dazu:
Ein Kennwort das aus einem "Empty String" besteht ist nicht das gleiche wie "überhaupt kein" Kennwort.

Wieder was dazugelernt - aber was ist der Unterschied zw. kein Passwort und "Empty String"?

Es ist nicht verboten, auch Dinge von fragwürdigster Nützlichkeit anzuzeigen.

In meinem Fall fand ich es durchaus nützlich, nur alle Gruppen und User die mit _ (Underscore) anfingen, benötigte ich doch nicht, war nur interessant was es da so alles gibt.

Unsinn. In der nackten "Out of the Box" Konfiguration hat dort *überhaupt kein* Benutzer ein Kennwort gesetzt.

Hier habe ich mich falsch ausgedrückt, wenn man einen User für ein Windows Service anlegt, so sollte man keinesfalls das Passwort leer lassen, sondern ein sehr, sehr kryptisches verwenden, natürlich muss der User in den dementsprechenden Berechtigungsgruppen sein. Manche Windows Services laufen unter System, nur bei manchen geht das so nicht. MS SQL und Exchange sind da spezielle Kandidaten.

Und nein, unter Windows können sich nur die Benutzer anmelden, die einen entsprechenden Hive in der Registry besitzen und dort die entsprechenden Berechtigungen gesetzt bekommen haben.

Das ist in Normalfall im AD so gesetzt, dass er sich anmelden könnte, wenn man einen User neu anlegt., mit Policies (die ja nichts anderes tun als Rechte in Gruppen setzten) kann man das verhindern. Man kann im Windows außer im AD auch User lokal anlegen (außer bei AD Domäncontrollern).

PS: Es ist nun schon eine Weile her, dass ich mich mit Windows Servern intensiv befassen musste, da habe ich so manche Details schon vergessen.

 

[Rastafari]

Hängt das etwa damit zusammen, dass OS X hier einen MicroKernel einsetzt?

Nein, das ist Banane. Hier zählen Kompatibilität zu gesetzten Mindeststandards etc.
Aber heutzutage darf man das auch als kleinkarierte Korinthenkackerei sehen, die sich nur an den auf unverschämte Weise erlangten und durchgesetzten Namensrechten am Warenzeichen 'Unix' einen runtermacht.
Fakt bleibt dennoch: OS X (und auch Windows!) sind voll POSIX-konform, Linux nur beinahe.

Sonst wird immer davon geschrieben, dass Mac OS X von BSD abstammt.

Das ist ähnlich halbfalsch wie die Aussage, der Mensch stamme vom heutigen Affen ab.
Richtiger wäre: OS X und die heute gängigen freien BSD-Varianten haben gemeinsame Vorväter.
Und sie haben sich im Lauf der Zeit immer wieder gegenseitig mit Verbesserungen infiziert.

Wieder was dazugelernt - aber was ist der Unterschied zw. kein Passwort und "Empty String"?

Wird ein Leerstring gesetzt, dann ist dieser ein ebenso gültiges Kennwort wie jedes andere - nur eben ultimativ primitiv zu kompromittieren.
Existiert dagegen gar kein Kennwort, gibt es auch nichts das erraten, dekodiert oder ausgespäht werden könnte - jeder Versuch kann nur fehlschlagen. Schlecht für Langfinger: An einer Türe, die überhaupt kein Schlüsselloch besitzt hilft dir kein Nachschlüssel und auch kein Dietrich weiter.

In meinem Fall fand ich es durchaus nützlich, nur alle Gruppen und User die mit _ (Underscore) anfingen, benötigte ich doch nicht, war nur interessant was es da so alles gibt.

Eine einfache Übersicht über alle von OD verwalteten Informationen erlangst du über die Systemeinstellung Benutzer / Anmeldeoptionen / Mit Netzwerkaccountserver verbinden... / "Verzeichnisdienste" öffnen...
Dieses Konfigurationstool bietet einen rudimentären OD-Verzeichnis-Editor an.
Sieh dich dort ruhig um. Die Darstellungen "Users" und "Groups" lassen zwar nur die Auflistung nach Vollnamen zu, dafür aber auch keine Geheimnisse offen.
Aber hüte dich davor, dort irgend etwas zu ändern.
Am besten, du öffnest nicht mal das Schloss dort, dann kommst du nicht in Versuchung bzw Gefahr. (Das Potential zum totalen Zerballern deines Systems liegt bei 10 von 10. Kein Spielplatz für Experimente.)

Das ist in Normalfall im AD so gesetzt, dass er sich anmelden könnte, wenn man einen User neu anlegt., mit Policies (die ja nichts anderes tun als Rechte in Gruppen setzten) kann man das verhindern.

Einzelnen Konten bzw Gruppen zB temporär das Login zu verweigern ist auch in OS X sehr trivial. Jedenfalls für Verwender des OS X Server - zu dem gibts ein "dickeres" OD-Verwaltungstool namens "Workgroup Manager", das von seiner Bedeutung her etwa den Policies von Windows entspricht.
Der funktioniert zwar prinzipiell auch mit der Client-Version - damit erreichst du aber schon den "Messer/Gabel/Schere/Licht" Level 11 von 10.

Man kann im Windows außer im AD auch User lokal anlegen (außer bei AD Domäncontrollern).

Und inwiefern ist das eine Besonderheit?

 

[MacAlzenau]

Existiert dagegen gar kein Kennwort, gibt es auch nichts das erraten, dekodiert oder ausgespäht werden könnte - jeder Versuch kann nur fehlschlagen. Schlecht für Langfinger: An einer Türe, die überhaupt kein Schlüsselloch besitzt hilft dir kein Nachschlüssel und auch kein Dietrich weiter.

An so einer Tür gibt es aber dann auch nur zwei Möglichkeiten. Entweder komme ich überhaupt nicht rein oder ich ziehe sie einfach auf.
Varianten wie Irisscanner, Zahlencodes usw. würden ja das Beispiel sprengen (oder wäre genau das, der Umweg, das Geheimnis?).
Ich will das Beispiel nicht überstrapazieren - aber diese passwortfreien Systembenutzer müssen doch das System auch benutzen. Wenn das ohne Passwort klappt, wieso ist das dann sicherer? Ich habe mir da nie Gedanken dazu gemacht, bin automatisch davon ausgegegangen, daß das alles irgendwie freigeschaltet wird, wenn sich ein Benutzer anmeldet, aber irgendwie irritiert mich, daß kein Paßwort sicherer ist als ein Paßwort. Und wenn mal ein Benutzer angemeldet ist, dann läuft da halt alles im Hintergrund so vor sich hin.
Oder sind diese Dienste sozusagen fest verdrahtet bei dem, was sie tun, ein Passwort (oder eben auch keines) bräuchte man nur für Änderungen gegenüber dem, was das Betriebssystem vorgibt?
Oder stehe ich einfach irgendwie völlig auf dem Schlauch?

 

[Rastafari]

aber diese passwortfreien Systembenutzer müssen doch das System auch benutzen.

Die betreffenden Programme brauchen doch einfach nur unter diesen Kennungen gestartet zu werden. root darf das. Und nur root kann das überhaupt. Was meinst du, sollte root vorher kurz bei root nachfragen, ob root etwas dagegen hat dass root mal für ein Weilchen nicht root sein will?

 

[MacAlzenau]

So auf Anhieb ist mir das nicht klar, muß ich mal setzen lassen. Wenn root das sowieso darf, wo ist dann der Zugewinn, wenn kein Paßwort geknackt werden muß? Klar, es wäre völlig unpraktikabel, wenn jeder dieser Benutzer noch ein eigenes Paßwort hätte, aber ich verstehe halt noch nicht, warum die Nichtexistenz des Paßwortes nochmal sicherer ist als wenn es eine gäbe. Oder überinterpretiere ich hier einfach und verrenne mich?
Zuerst fällt mir aber bei der Nachfragerei der schöne, wenn auch hier nur des Witzes wegen passende Satz ein "You're never alone with a schitzophrenic".

 

[FritzS]

Ist zwar nicht genau das Thema - passt aber dazu.

Und selbst root kann man mittels Sandboxing "entrechten" (1) - das habe ich bei meinem Einrichten von ISC BIND named durch try ans error erfahren können.

(1) Hier müsste root selbstständig die Sandboxing Konfigurationsdatei ändern.

PS: Was ist denn eigentlich sicherer, chroot, jail oder sandboxing?

 

[FritzS]

Einzelnen Konten bzw Gruppen zB temporär das Login zu verweigern ist auch in OS X sehr trivial. Jedenfalls für Verwender des OS X Server - zu dem gibts ein "dickeres" OD-Verwaltungstool namens "Workgroup Manager", das von seiner Bedeutung her etwa den Policies von Windows entspricht.

Der Workgroupmanager ist genau das was ich suchte - auf 127.0.0.1 verbunden und man sieht alles.
Und ich weiß dass man unter "Unix" alles ohne "Vorwarnung" zerschießen kann.

Was soll man mit definitiv verwaisten User & Gruppen machen? Bei mir geistern da noch User & Gruppen von "Glimmerblocker" und "MacPorts" am System herum, die Programme dazu sind schon längst entfernt.. Dazu gibt es sicherlich auch eine Datei in

/private/var/db/launchd.db/com.apple.launchd.peruser.

(muss noch mit der UID suchen).

PS: Ich will meinen Mac nicht neu aufsetzten um alten Schrott zu entfernen.