Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Sudo Password will er nicht

Sudo Password will er nicht

PLOENI
PLOENI03.03.0914:18
Wollte Call of Duty 2 nach Quicktime 7.6 mittels der sudo-Anweisungen wieder zum laufen bringen, nur akzeptiert das Terminal alle Passwörter nicht. Kann mich eigentlich nicht erinnern, dort eins vergeben zu haben.

Kann mir jemand weiterhelfen? z. B. Wie man das Password zurücksetzt ohne es zu kennen?

Schon mal Danke an alle
„Think different with a Mac“
0

Kommentare

exAgrajag03.03.0914:40
Du kannst sudo nur mit einem Account benutzen, was Admin-Rechte besitzt, also in der sudoers list stehen. Das von sudo verlangte Passwort, ist das des aktuellen Users. Das hast du also beim Einrichten des OSX-Users schon vergeben.
0
PLOENI
PLOENI03.03.0914:54
Nur genau das funzt nicht. Er sagt es sei falsch! Und was nun?
„Think different with a Mac“
0
sierkb03.03.0915:10
PLOENI
Nur genau das funzt nicht. Er sagt es sei falsch! Und was nun?

WAS genau funzt nicht. Zum Verständnis nochmal: Nur ein Benutzer mit Admin-Rechten kann/darf unter MacOSX das sudo-Kommando überhaupt absetzen und sich via sudo-Kommando als Superuser root (dafür steht das 'su' in 'sudo') identifizieren. Um das sudo-Kommando also überhaupt absetzen zu können, musst Du also bereits die Identität des Admin-Benutzers angenommen haben (der zwar Admin-Rechte hat aber immer noch keine so weitgehenden Rechte wie der Superuser root).
Und das machst Du z.B. entweder, indem Du Dich als Admin einloggst und dort im Terminal vorstellig wirst, oder, wenn Du Dich als normaler Nutzer in Deinem Standard-Account befindest, Du nimmst im Terminal erstmal die Identität des Admin-Users an mit 'su admin' und entsprechendem Passwort. Und dann erst, nachdem Du erfolgreich im Terminal als Admin eingeloggt bist (nachprüfbar z.B. mit dem Kommando 'whoami'), dann erst kann st Du das sudo-Kommando überhaupt absetzen. Und dann musst Du zur Identifizierung das Passwort für den Superuser root angeben. Und das setzt voraus, dass dieser Superuser root von Dir zuvor überhaupt aktiviert worden ist (der ist bei MacOSX nämlich standardmäßig deaktiviert, und Du musst ihn erstmal aktivieren via /Applications/Utilities/Verzeichnisdienste Bearbeiten) und Du diesem Superuser root im Zuge dessen überhaupt ein Passwort zugewiesen hast.

Alles klar?
Der normale Nutzer ohne Admin-Rechte ist normalerweise nicht befugt, die Identität des root-Users anzunehmen oder Kommandos mit dessen Verfügungsgewalt abzusetzen. Und das ist auch gut so.

Der Admin-User ist z.B. u.a. Mitglied der Unix-Gruppe wheel. Das ist die Gruppe, die das sudo-Kommando absetzen darf.
In der Datei /etc/sudoes steht drin, wer das Kommando absetzen darf. Das ist i.d.R. root selber und eben der Admin-User (der da reinkommt in diese Datei, sobald er vom System Admin-Rechte zugesprochen bekommen hat). Editieren darf diese Datei nur root bzw. das System selber. Auch das ist gut so und sollte Dich nicht weiter kümmern.
0
MacMark
MacMark03.03.0915:28
Ich habe die Postings mal überflogen. Dabei sprangen mir zwei Stachel ins Auge:

*Hust* Admins sind in der admin-Gruppe. In wheel ist nur root.

*Megahust* Eine GUI-App, vulgo "Spiel", unter (per sudo) root laufen lassen zu wollen, ist eine ganz unschöne Idee.
Niemals GUI unter root, auch später nicht und danach auch nicht.
„@macmark_de“
0
sierkb03.03.0916:01
MacMark
Ich habe die Postings mal überflogen. Dabei sprangen mir zwei Stachel ins Auge:

*Hust* Admins sind in der admin-Gruppe. In wheel ist nur root.

Stimmt, Du hast vollkommen recht. Ich hätte es mal via 'dscl . -read /Groups/wheel GroupMembership' oder einem Blick in /etc/group nachprüfen sollen...
Hatte halt noch das wohl veraltete Apple Support-Dokument im Gedächtnis, welches das etwas anders darstellt, und ich habe es, um's schnell hinschreiben zu können, dann einfach ungeprüft so übernommen (habe zwar schnell in /etc/group reingeschaut, doch die Diskrepanz nicht weiter beachtet). Mea culpa.
*Megahust* Eine GUI-App, vulgo "Spiel", unter (per sudo) root laufen lassen zu wollen, ist eine ganz unschöne Idee.
Niemals GUI unter root, auch später nicht und danach auch nicht.

Meine volle Zustimmung. Hatte ich im Vorbeigehen übersehen, dass er DAS evtl. vorhaben könnte (da bin ich wohl ein wenig zu ungründlich auf die Frage eingegangen). Das geht ja nun mal gar nicht, wenn dem so sein sollte und er sowas vorhaben sollte...
0
Wowbagger03.03.0916:09
PLOENI
Was willst Du überhaupt mit sudo anstellen? Es scheint doch einen Patch zu geben:

0
sierkb03.03.0916:19
MacMark
Admins sind in der admin-Gruppe. In wheel ist nur root.

Das scheint unter MacOSX wohl nicht immer so gewesen zu sein, sondern hat annahmsweise wohl erst Einzug erhalten, als mehr GNU Software in den Unix-Unterbau von MacOSX übernommen worden ist (z.B. die Bash). Grund für meine Annahme: . Es gab also anscheinend mal Zeiten, da hatte die Gruppe wheel auch unter MacOSX (so wie in anderen altehrwürdigen Unices) noch einen höheren Stellenwert als derzeit, das ist mit der Verbreitung von GNU wohl alles ein wenig "entbürokratisiert" worden.
Denke ich mal.
0
MacMark
MacMark03.03.0918:27
In dem 2001er Apple-Artikel geht es um "su", nicht um "sudo". Wheel war schon immer die Gruppe von root. Vor OS X 10.2 waren auch Admins in wheel. Seit 10.2 nicht mehr. Vergleiche
Users, Groups, and Permissions
„@macmark_de“
0
g-kar03.03.0918:53
sierkb
nachdem Du erfolgreich im Terminal als Admin eingeloggt bist (nachprüfbar z.B. mit dem Kommando 'whoami'), dann erst kann st Du das sudo-Kommando überhaupt absetzen. Und dann musst Du zur Identifizierung das Passwort für den Superuser root angeben. Und das setzt voraus, dass dieser Superuser root von Dir zuvor überhaupt aktiviert worden ist

Hmm, bei mir hat die Gruppe admin auch das Recht, sudo auszuführen. Als Admin kann ich also sudo benutzen und mein normales Admin-Passwort verwenden, ohne root aktiviert zu haben.

0
MacMark
MacMark03.03.0919:10
g-kar
… Gruppe admin … das Recht, sudo auszuführen. Als Admin kann ich also sudo benutzen und mein normales Admin-Passwort verwenden, ohne root aktiviert zu haben.

So ist es.
Einzelne Befehle mit root-Rechten laufen lassen können per sudo ohne daß ein ganzer Account mit all seinen Prozessen root sein muß. Denn dann hätte man Millionen von Befehlen unter root am Laufen.
„@macmark_de“
0
sierkb03.03.0919:11
MacMark
In dem 2001er Apple-Artikel geht es um "su", nicht um "sudo"

Wer das sudo-Kommando absetzen darf, regelt die root vorbehaltene /etc/sudoers.
Dort wird per Grundkonfiguration von MacOS X nur der drin vermerkt, wer von den einschlägigen System-Tools zur Nutzerverwaltung Admin-Rechte zugestanden bekommen hat. Oder man ändert es händisch und trägt auch zusätzlich Nicht-Admin-Nutzer ein. Davon ist aber im Sinne der Sicherheit tunlichst abzuraten, und nicht umsonst ist das per Default nicht so konfiguriert bzw. müsste man ggf. erst root-Rechte haben, um /etc/sudoers überhaupt einsehen geschweige denn mittels visudo editieren zu können/dürfen.
Wheel war schon immer die Gruppe von root.

Und derer, die root-Rechte haben wollen, zumindest in klassicher BSD-Umgebung. Apple hat das mit MacOSX 10.3 geändert und die Gruppe "wheel" quasi funktionslos bzw. überflüssig gemacht zugunsten der Gruppe "admin". Siehe dazu u.a. auch .
Vor OS X 10.2 waren auch Admins in wheel. Seit 10.2 nicht mehr. Vergleiche
Users, Groups, and Permissions

Ja. Siehe auch .
0
sierkb03.03.0919:28
g-kar
Hmm, bei mir hat die Gruppe admin auch das Recht, sudo auszuführen. Als Admin kann ich also sudo benutzen und mein normales Admin-Passwort verwenden, ohne root aktiviert zu haben.

Das ist korrekt und soll auch so sein. Seit MacOSX 10.3 hat die admin group die wheel group in dieser Funktionalität abgelöst.

Wenn Du Dir als Admin-Benutzer im Terminal eingeloggt mal die Datei /etc/sudoers mit 'sudo less /etc/sudoers' anzeigen lässt, dann wirst Du darin wahrscheinlich u.a. folgenden wesentlichen Eintrag finden:

# User privilege specification
root    ALL=(ALL) ALL
%admin  ALL=(ALL) ALL

# Uncomment to allow people in group wheel to run all commands
# %wheel        ALL=(ALL)       ALL

Demnach haben der Benutzer root und die Gruppe admin also das Recht, ein sudo-Kommando abzusetzen. Niemand sonst. Die Gruppe wheel nicht (mehr), weil der betreffende Eintrag mit einem "#" auskommentiert ist.

Alles klar?
0
MacMark
MacMark03.03.0921:51
Wheel ist weder funktionslos noch überflüssig, denn jeder User muß in mindestens einer Gruppe sein. Root ist in wheel.
„@macmark_de“
0
PLOENI
PLOENI04.03.0911:40
Das Problem war ich selbst

Der Admin hatte gar kein Passwort, daher konnte sudo nicht aktiviert werden. Ich schäme mich ja so ... :'(

Und obwohl es für CoD2 den 7.6-Patch gibt (Aspyr stellt selbst noch einen zweiten zur Verfügung: siehe , scheint der anschließend nur zu funzen, wenn man folgendes per Terminal zusätzlich eingibt:

$ cd /usr/lib
$ sudo cp libcrypto.0.9.dylib libcrypto.0.9.dylib.old
$ sudo cp libssl.0.9.dylib libssl.0.9.dylib.old
$ sudo ln -sf libcrypto.0.9.7.dylib libcrypto.0.9.dylib
$ sudo ln -sf libssl.0.9.7.dylib libssl.0.9.dylib

Nun verlagt CoD2 zwar wieder nach der DVD, aber es läuft wieder.

Und nochmal Sorry, wegen meiner Schlampigkeit.
„Think different with a Mac“
0
exAgrajag04.03.0911:42
PLOENI
Das Problem war ih selbst

Der Admin hatte gar kein Passwort, daher konnte sudo nicht aktiviert werden. Ich schäme mich ja so ...
Huh... Das ist wohl nicht der einzige Grund, warum es eine ÄUSSERST schlechte Idee war, kein Passwort auf ein Admin-Account zu setzen...
0
sierkb04.03.0911:58
MacMark
Wheel ist weder funktionslos noch überflüssig

Deshalb schreibt Apple ja auch unter zur wheel-Gruppe :

"The Wheel Group
There is a special group in BSD called the wheel group. Membership in the wheel group confers on users the ability to become the root user by using the su utility on the command line. Users who are not in the wheel group can’t become the root user, even if they have the correct password. In Mac OS X v 10.3 and later, the wheel group is not used. Its functions have been assumed by the admin group."

denn jeder User muß in mindestens einer Gruppe sein.

Das bestreitet auch niemand, das steht außer Frage.
Root ist in wheel.

Siehe oben. Eventuell lungert wheel da unter MacOSX noch als Relikt herum, um die Kompatibilität mit anderer Software aus dem BSD- und GNU-Universum zu gewährleisten (z.B. verschiedene Tarballs), die sich z.B. mit chown root:wheel installieren will. Für den Betrieb unter MacOSX ist die Gruppe wheel wohl weitgehend funktionslos geworden, unter anderen BSDs hat sie die Bedeutung, die ich zuvor ursprüngl. irrigerweise auch für MacOSX angenommen hatte. Diese Bedeutung hat Apple jedoch, so wie es aussieht, der wheel-Gruppe komplett genommen und sie der (evtl. neu ins Feld geführten?) admin-Gruppe übertragen. Was übrig bleibt, ist anscheinend ein weitgehend funktionsloses Relikt (wheel) zwecks besserer Kompatibilität zur restlichen BSD-Welt.

Oder?
0
sierkb04.03.0912:04
PLOENI
Der Admin hatte gar kein Passwort, daher konnte sudo nicht aktiviert werden.


Wenn ich sowas lese, dann packt mich schon wieder das kalte Grauen...
Ich darf dann wohl auch fast annehmen, dass das dann auch Dein einziger Account auf dem betreffenden Rechner ist (Du also nicht getrennt hast zwischen Admin-Account und Nicht-Admin-Account) und Du wirklich komplett ALLES unter diesem einen Account und ausgestattet mit Admin-Rechten machst?
0
MacMark
MacMark04.03.0913:05
Warum sollte wheel funktionslos sein, nur weil Admins nicht darin sind? Wheel (Group ID 0) ist die primäre Gruppe von root (User ID 0). Das ist doch eine sehr schöne Funktion.

Admins (Group ID 80) sollen sudo-berechtigt, aber nicht Mitglied von wheel sein. Root als einziges Mitglied von wheel ist auch Mitglied in admin und dadurch sudo-berechtigt. Damit ist eine sudo-Berechtigung für wheel überflüssig, also auskommentiert.

Die Anzahl der User in wheel gering zu halten ist auch ein Ziel, wenn man BSD sicherer macht.
„@macmark_de“
0
sierkb04.03.0913:32
MacMark
Warum sollte wheel funktionslos sein, nur weil Admins nicht darin sind?

U.a. deswegen, weil Apple das selber so sagt bzw. schreibt, Markus.

Oder wie interpretierst Du die Aussage "In Mac OS X v 10.3 and later, the wheel group is not used. Its functions have been assumed by the admin group."
Wheel (Group ID 0) ist die primäre Gruppe von root (User ID 0). Das ist doch eine sehr schöne Funktion.

Ja und? Was nützt allein die Existenz derselben, wenn das OS keinen Gebrauch (mehr) davon macht?
Admins (Group ID 80) sollen sudo-berechtigt, aber nicht Mitglied von wheel sein. Root als einziges Mitglied von wheel ist auch Mitglied in admin und dadurch sudo-berechtigt. Damit ist eine sudo-Berechtigung für wheel überflüssig, also auskommentiert.

Eben! Damit ist die wichtigste Existenzberechtigung für die unter BSD-Unices übliche Gruppe wheel von Apple komplett wegrationalisiert bzw. auf die Gruppe admin übertragen worden, Apple schreibt es doch in seinen Dokumenten selbst! Admins/Co-Admins, die su-berechtigt sein sollen, die sind unter BSD-Unices normalerweise Mitglied der Gruppe wheel (allein dafür ist diese Gruppe wheel da), wer das sudo-Kommando absetzen darf, steht darüberhinaus noch in /etc/sudoers.

Apple hat das alles im Gegensatz zu der bisher BSD-üblichen Weise zusammengefasst, indem sie diese Berechtigungen/Aufteilungen alle auf die Gruppe admin übertragen haben (welche unter BSD Unices wahrscheinlich so nicht existiert, habe grad' kein anderes BSD zum Nachprüfen da). Die unter BSD gebräuchliche Gruppe wheel ist damit unter MacOSX funktionslos geworden. Außer dass da standardmäßig root Mitglied drin ist wird vom OS kein weiterer Gebrauch von dieser Gruppe gemacht (zwecks Kompatibilität zu z.B. aus Tarballs installierter/kompilierter Software sollte die Gruppe wheel wenigstens der Form halber existieren und wenigstens der Form halber einen User (nämlich den Superuser root) beherbergen -- was derzeit auch so der status quo ist).

D'accord?
0
MacMark
MacMark04.03.0913:51
Apple bezieht sich auf die Admins, die eine separate Gruppe bekamen. Wheel wird dennoch gebraucht: Für root. Wenn Du überzeugt bist, wheel wäre funktionslos, dann entferne die Gruppe doch mal
sierkb
... Admins/Co-Admins, die su-berechtigt sein sollen, ...sind ... Mitglied der Gruppe wheel ..., wer das sudo-Kommando absetzen darf, steht darüberhinaus noch in /etc/sudoers. ...

Streiche "darüberhinaus noch"

Wenn Du ein anderes BSD sicher machst, dann fliegt auch alles aus wheel raus (außer root).

Wenn Du magst, füg doch Admins zu wheel hinzu.
„@macmark_de“
0
sierkb04.03.0914:22
MacMark
Streiche "darüberhinaus noch"

OK.
Wenn Du ein anderes BSD sicher machst, dann fliegt auch alles aus wheel raus (außer root).

Siehe u.a. . Nur mit dem Unterschied, dass diese Gruppe unter anderen BSDs auch noch eine Funktion und Bedeutung hat und die damit verbundene Funktionaliät in Verbindung mit dieser wheel-Gruppe vom betreffenen OS (FreeBSD, NetBSD, OpenBSD und wohl auch Solaris) auch abgefragt wird. Apple hat die Funktionalität dieser für Admin-Zwecke vorhandenen Gruppe namens "wheel" jedoch seit MacOSX 10.5.3 auf die admin-Gruppe übertragen -- einer Gruppe, die andere BSD-Systeme meiner Kenntnis nach so nicht kennen bzw. so nicht haben (Linux-Systeme übrigens kennen keine wheel-Gruppe).

Die Frage stellt sich mir, was passieren würde, wenn man jetzt auch noch den letzten verbliebenen Nutzer root der wheel-Gruppe unter MacOSX entfernen, die wheel-Gruppe also leer sein würde (root ist ja unter MacOSX Mitglied der admin-Gruppe, das sollte doch reichen)...
Würde das folgenlos bleiben -- eingedenk der Tatsache, dass Apple hier spätestens seit 10.5.3 von dem abweicht, was unter anderen BSD Unices Usus ist und wo die wheel-Gruppe ja noch eine zentrale Bedeutung bzgl. der Administration des Systems hat? Oder was würde passieren?
0
HR04.03.0914:39
Wenn man Admin ist und sich gut auskennt kann man gut mit

sudo bash

arbeiten
Dann braucht man auch kein su root.
0
MacMark
MacMark04.03.0914:59
sierkb
Es sind nur User von wheel nach admin gewandert. Wheel ist weiterhin das, was es vorher war. Unter anderen BSDs verliert wheel ja auch nicht an Bedeutung, wenn man dort User entfernt, um es abzusichern.
Apple weicht von gar nichts ab damit. Jedes BSD macht das zur Absicherung genauso.
HR
...
sudo bash
...
Dann braucht man auch kein su root.
Mit su wechselt man die Identität. Das passiert bei sudo nicht. Dort wird nur ein Befehl (hier bash) unter einem anderen User ausgeführt. Ferner kann sudo so eingeschränkt konfiguriert sein, daß Dein obiger Befehl Dir nicht hilft.

PS: "sudo -s" ist eleganter
„@macmark_de“
0
sierkb04.03.0915:03
HR
Wenn man Admin ist und sich gut auskennt kann man gut mit
sudo bash
arbeiten

Sofern man die Bash als seine Standard-Shell eingestellt hat. Was per default ja der Fall ist, der eine oder Andere bevorzugt jedoch bspw. die Z-Shell (zsh)...

Es ginge auch noch kürzer: sudo -s
Aber das nur nebenbei.
Dann braucht man auch kein su root.

Um derlei Abkürzungen geht's hier bisher aber irgendwie nicht, Voraussetzung auch für solche Abkürzungen ist und bleibt, dass man dazu berechtigt ist und diese Berechtigung irgendwo vermerkt ist...
Oder irre ich?
0
sierkb04.03.0915:09
MacMark
sierkb
Es sind nur User von wheel nach admin gewandert. Wheel ist weiterhin das, was es vorher war.

Sagst Du. Apple sagt: "In Mac OS X v 10.3 and later, the wheel group is not used. Its functions have been assumed by the admin group."
Unter anderen BSDs verliert wheel ja auch nicht an Bedeutung, wenn man dort User entfernt, um es abzusichern.

Dort gibt es auch keine Gruppe admin und auch keine Aussage wie die von Apple, dass da Funktionen der einen Gruppe von der anderen Gruppe angenommen worden sind... Unter anderen BSDs hat die Gruppe wheel die seit Jahren bekannte Funktion, keine andere Gruppe scheint zu existieren, die ihr diese Funktion streitig macht. Und das ist wohl unter MacOSX ein wenig anders (geworden) bzw. wird da ein wenig anders gehandhabt.
Apple weicht von gar nichts ab damit. Jedes BSD macht das zur Absicherung genauso.

Siehe zuvor Gesagtes.
PS: "sudo -s" ist eleganter

Zwei Leute -- ein Gedanke.
0
MacMark
MacMark04.03.0916:01
OS X ist in dem Punkt "wheel oder admin" halt sicherer, weil Admins nicht in wheel sind. Das ist eine Verbesserung.
Die wheel-Gruppe ist hinsichtlich Admins "not used". Die "Funktion" Admins_sind_in_mir hat sie verloren, aber sonst nichts.
Wie gesagt: Lösch wheel und dann reden wir nochmal über "not used". Apple drückt sich auch nicht immer unmißverständlich aus
„@macmark_de“
0
sierkb04.03.0916:42
MacMark
OS X ist in dem Punkt "wheel oder admin" halt sicherer, weil Admins nicht in wheel sind. Das ist eine Verbesserung.

Dafür sind sie in der Gruppe admin. Was ist daran eine Verbesserung? Erst recht im Sinne von Sicherheit? Nur umgruppiert, dem Baby einen neuen Namen gegeben. Sonst nichts.
Die wheel-Gruppe ist hinsichtlich Admins "not used". Die "Funktion" Admins_sind_in_mir hat sie verloren, aber sonst nichts.

"Sonst nichts" ist gut. Das IST bzw. WAR ihre einzige Funktion gewesen. Für keinen anderen Zweck existiert die Gruppe wheel. Jedenfalls nach meinem Verständnis und nach allem, was ich bisher drüber weiß und lesen kann und auch auf der su-Manpage von MacOSX so lesen kann.

Nun gib doch schon endlich zu, dass Apple hier die Gruppe "wheel" komplett ihrer ursprünglichen und eigentlichen Funktion beraubt und diese Funktionalität nun voll und ganz der admin-Gruppe zugesprochen hat!

Daran muss ja grundsätzlich nichts Schlechtes sein, wie gesagt: unter Linux kommt man auch ohne wheel-Gruppe aus. Nur sollte Apple diesen Schritt halt sauber vollzogen haben. Und da könnte es evtl. Zweifel geben.
Wie gesagt: Lösch wheel und dann reden wir nochmal über "not used".

Ausprobieren werde ich das sicher nicht. Hatte da eher eine befriedigende Antwort von Dir erwartet, ohne es "am lebenden Objekt" direkt ausprobieren zu müssen. Aber offenbar bist Du Dir da selber nicht ganz sicher...
Apple drückt sich auch nicht immer unmißverständlich aus

Ich finde die zitierten Sätze eigentlich verständlich genug. Darüber hinausgehende Klarheit wollte ich eigentlich von Dir erfahren, aber wie es ausschaut, bist Du Dir da auch nicht so sicher, was das angeht.

Und Apple hat in der Vergangenheit so manches Mal am Basis-System herumgeschraubt und etwas abseits der üblichen Gepflogenheiten "gedreht", das sich nachher als nicht so glücklichen Griff erwiesen und teilweise wieder rückgängig gemacht oder auf andere Weise korrigiert/begradigt werden musste. Beispiel: das Hin und her mit den ganzen Benutzern- und Gruppen und ihren Rechten (vergleiche dazu Pre-Tiger, Tiger, Leopard). Weiteres Beispiel: die Geschichte mit den userspezifischen Cache- und Temp-Ordnern, deren neue Lokalität unter /var/folders/ und die damit verbundenen neuen Probleme bzgl. Verschlüsselung und privater Sicherheit Dir ja offenbar auch nicht so richtig schmecken mögen, wenn ich Dich richtig interpretiert habe, was Du an anderer Stelle unlängst geschrieben hast...

Nicht immer schraubt bzw. ändert Apple am Basis-System was, was unterm Strich wirklich zu Ende gedacht ist (das haben sie an zahlreichen Stellen bisher gezeigt), und ich habe diesbzgl. anscheinend eine etwas höhere Skepsis solchen eigenwilligen Veränderungen gegenüber als Du es bisher zumindest zuzugeben scheinst -- erst recht, wenn es dann auch noch von Dritten begründet wird, es habe schon noch alles seinen Sinn und seine Richtigkeit, was Apple da so tue. Das mag im Großen und Ganzen wohl stimmen, doch einen Persilschein möchte ich da Apple eigentlich ungern ausstellen.

Zurück zum Thema: wenn ich mir Deine letzten Antworten so ansehe, dann subsummiere ich, dass Du eigentlich bzgl. der wheel-Gruppe auf meine Sicht eingeschwenkt zu sein scheinst, jedenfalls ist Dir da offenbar keine neue plausible gegenteilige Meinung zu eingefallen.
0
MacMark
MacMark04.03.0918:25
hüstel
Auf BSD-Systemen besteht die Gruppe wheel per default nur aus root.

Wheel ist der "Group Owner" der meisten Systemdateien.
Admin ist das nicht.
So auch bei OS X.

Systeme, auf denen der Normal-User nicht per "su root" root werden kann,
selbst wenn er das root-Paßwort kennt
(und root enabled ist und das root Paßwort gesetzt ist), sind sicherer als solche Systeme, auf denen
jeder, der das root-Paßwort kennt, root werden kann.
„@macmark_de“
0
sierkb04.03.0918:54
MacMark

Auf BSD-Systemen besteht die Gruppe wheel per default nur aus root.

Bei der Erstinstallation, natürlich. Und dann? Wie verhalten sich diese anderen BSD-Systeme bzgl. der Einrichtung eines Non-Privileged Users bei der Erstinstallation des Systems? Bleibt root der einzige Nutzer des Systems? Bleibt root der einzige Nutzer, der einen Eintrag in wheel erhält? Kannst Du mir das freundlicherweise sagen?
Wheel ist der "Group Owner" der meisten Systemdateien.
Admin ist das nicht.
So auch bei OS X.

Soweit korrekt. Das hatte ich übersehen.
Das bezieht sich allerdings nur auf die Verzeichnisse /System, (das standardmäßig leere) /Network, /bin, (das virtuelle) /dev, /private, /sbin und /usr. Und den Kernel unter / natürlich. Von /Library und den meisten Unterverzeichnissen darin ist z.B. der Group Owner nicht wheel, sondern admin. Ich würde /Library jetzt auch mal als nicht verzichtbares System-Directory bezeichnen, trotzdem gehört es der Gruppe admin bzw. ist durchsetzt von Unterverzeichnissen, die admin gehören. Unter anderen BSD-Systemen würden wahrscheinlich auch diese Verzeichnisse der Gruppe wheel gehören. Oder?
Welcher Logik, welchem System folgt das Ganze unter MacOSX also? Dass man nicht immer eine einheitliche Logik und ein einheitliches System unter MacOSX entdecken kann, was sowas betrifft, hast Du an anderer Stelle (ich sage nur /var/folders) ja schon in ähnlicher Form zum Ausdruck gebracht. Und da würde ich Dir auch recht geben.
Systeme, auf denen der Normal-User nicht per "su root" root werden kann,
selbst wenn er das root-Paßwort kennt
(und root enabled ist und das root Paßwort gesetzt ist), sind sicherer als solche Systeme, auf denen
jeder, der das root-Paßwort kennt, root werden kann.

Zutreffend sowohl für die Gruppe admin als auch für die Gruppe wheel.
Zudem hat Apple seine Default-Installation in dieser Hinsicht wieder ein Stück von der angeblich damit zu bewirkenden höheren Sicherheit abgerückt, indem der Default-User erstmal standardmäßig Mitglied der Gruppe admin ist (und damit Admin-Rechte hat und damit wiederum sehr in die Nähe von root gerückt und lediglich ein einziges Passwort davon entfernt ist). Wohl gemerkt: der Default-User. Apple macht bei der Grundinstallation leider keine Anstalten, das dem Benutzer begreifbar zu machen, ermahnt oder zwingt ihn nicht, sogleich einen Nicht-priviligierten Nutzer anzulegen für den alltäglichen Gebrauch. Damit wird das ganze Konzept unnötig geschwächt,die ganze Argumentation bzgl. höherer Sicherheit und Trennung in admin-Gruppe bzw. wheel-Gruppe einer ziemlichen Schwächung unterworfen.
Ich kann mir nicht vorstellen, dass Du das bestreiten willst.


P.S.: Deine vielen Smileys habe ich zugunsten größerer Übersichtlichkeit/Lesbarkeit beim Zitieren mal geflissentlich gelöscht, ich hoffe, das ist OK.
0
MacMark
MacMark04.03.0921:12
sierkb
Welcher Logik, welchem System folgt das Ganze unter MacOSX also?
Die /Library ist Admin-Domäne. System-Domäne ist /System/Library. User-Domäne ist ~/Library und so weiter …
Ich kann hier keine Online-UNIX-Schulung geben, daher würde ich einfach zu ein paar guten Bücherm über UNIX-Systemadministration und über OS X raten. So etwas wie "Essential System Administration" von Æleen Frisch und "Mac OS X Internals" von Amit Singh.

OS X geht mit dem Admin-Konzept einen guten Mittelweg. Admins können lokale Programme installieren, aber nur root kann Systemprogramme installieren. Das ist eine wichtige Stelle, an der root vermieden wird und trotzdem nicht jeder rumpfuschen kann. Normale User können in ~/Applications installieren. Admins können das System nicht ändern; das kann nur root. Trotzdem haben Admins genügend Rechte, um die täglichen Dinge, die ein installier- und probier-freudiger User benötigt, erledigen zu können ohne root zu werden.
Bei vielen anderen Unices und GNU/Linux wird root nicht so konsequent vermieden wie auf OS X.
„@macmark_de“
0
sierkb04.03.0921:52
Bzgl. Unix-Schulung habe ich da eigentlich wenig Nachholbedarf. Deine diesbzgl. Ausführungen dazu sind mir geläufig, ich habe sie -- teilweise sehr detailreich -- hier bei MTN auch schon mehrfach anderen vermittelt (auch bevor Du hier bei MTN Deine Mitgliedschaft wiedererlangt hattest). Auch unter Nennung von Links zu einschlägigen Developer Dokumenten.
OS X geht mit dem Admin-Konzept einen guten Mittelweg.

Das wird sich noch herausstellen, ob der gut ist bzw. ob man dabei an alles gedacht und keine Fehler gemacht hat.
Bis 10.3 scheint es diesbezüglich ja anders gewesen zu sein, von Tiger auf Leopard hat man dann wiederum an den Benutzergruppen und Zuordnungen herumgebastelt (Stichwort: staff-Gruppe versus GUID=UID in Tiger) -- um es im Grunde seitdem genau so zu machen, wie man es offenbar auch unter Panther gemacht hatte und wie es bei den anderen Unices bislang auch üblich ist.
Bei vielen anderen Unices und GNU/Linux wird root nicht so konsequent vermieden wie auf OS X.

Ich sage nur: wheel-Gruppe bei den BSDs. Kein Grund, die Nase zu rümpfen.

Alles in allem hat Apple schon mehr als einmal am Grundsystem herumgedoktert, es manchmal (nicht nur ich meine: ohne Not) sogar verschlimmbessert, sodass es danach wieder in mehreren Anläufen korrigiert oder gar still und leise zurückgenommen werden musste.

Ich habe also keinen Anlass zu glauben, dass diese Geschichte, über die wir beide hier so diskutieren, das letzte Wort bei Apple ist und man nicht evtl. ab irgendeiner Version von MacOSX wieder Abstand von der eigenen admin-Gruppe nimmt, wheel wieder die Bedeutung zukommen lässt, die es in den anderen BSDs seit jeher hat (und bei MacOSX auch mal hatte) und sich damit dann wieder mit dem Rest der BSD-Welt in gleichem Takt befindet. Die Rückgängigmachung des vorübergehenden UID=GUID-Konzeptes, das man sich während der Tiger-Ära gegönnt hat, spricht diesbzgl. Bände und lässt zumindest mich etwas vorsichtiger werden mit Aussagen, Apple wüsste immer genau, was sie da tun und ändern. Für meinen Geschmack ist das an mancher Stelle zuviel Eigenbrödlerei, die nicht immer wirklich ausgegoren und schon gar nicht abgestimmt zu sein scheint mit dem Rest der BSD-Welt. Und nach allem, was man aus der Unix-Community so lesen kann, deckt sich diese Einschätzung und dieses Gefühl mit dem meinigen. Apple schraubt manchmal viel am Basis-System, ändert mal hier was, dann mal da was. Und manchmal liegt man da offenbar ein wenig daneben -- manchmal an Stellen, die man besser in Ruhe gelassen oder sich vorher besser mit der restlichen Unix-Welt darüber verständigt hätte. Bei Apple darf und muss man also auf alles gefasst sein, da werden manchmal tradierte Konzepte einfach mal ohne Abstimmung mit dem Rest der Unix-Welt geändert oder über den Haufen geschmissen. In der stillen Hoffnung, es besser gemacht zu haben (was aber nicht immer gesagt ist, dass dieser Erfolg auch eintritt).

Und damit will ich's erstmal bewenden lassen.
0
MacMark
MacMark04.03.0922:25
Die Admin-Gruppe gibt es schon ewig. Nur waren diese Admins vor 10.2 zusätzlich in wheel.
„@macmark_de“
0
sierkb04.03.0922:34
MacMark
Die Admin-Gruppe gibt es schon ewig. Nur waren diese Admins vor 10.2 zusätzlich in wheel.

Wo kann ich das, andere BSDs betreffend, nachlesen?
Und wenn's nur MacOSX betrifft, wo die Gruppe admin existiert: viel mehr Sicherheit ist dadurch nicht gewonnen (auch wenn gewisse System-Dateien der Gruppe wheel gehören, der standardmäßig nur root angehört). Erst recht nicht, wenn der bei der Installation eingerichtete Default-User mit Admin-Rechten ausgestattet ist und das auch so bleibt bzw. der User nicht angehalten wird,das zu ändern. Nichts Halbes und nichts Ganzes in meinen Augen bzw. auf halbem Wege stehengeblieben. Oder?
0
MacMark
MacMark05.03.0908:25
Ohne Admin-Gruppe müßte man /Applications und /Library an root geben. Dadurch wäre man regelmäßig gezwungen, dort root zu nutzen (per sudo oder su), obwohl dort keine Systemdaten liegen.
Mit Admin-Gruppe können diese Arbeiten ohne root erledigt werden - also ein Sicherheitsgewinn.

Deshalb wäre der "ganze Weg" (keine Admins, nur Normal) riskanter, weil man öfter root werden müßte. Je mehr root, desto größer die Angriffsfläche und etwaige Fehlerauswirkungen.
„@macmark_de“
0
sierkb05.03.0913:16
MacMark:

Es kann ja durchaus sein, dass da hehre Gedanken dahinterstehen. Doch wird dieses Vorgehen/diese Notwendigkeit auch unter anderen Unix-Systemen genauso gesehen?
Wie wird diese Frage unter den anderen BSD-Systemen gesehen und gehandhabt, besonders unter dem ja seit Jahren auf höchste Sicherheit bedachten OpenBSD? Wie wird das unter FreeBSD, OpenBSD und auch Solaris gehandhabt?
Gibt es da Übereinstimmungen mit Apple in dieser Frage, was die Gruppe wheel und die Gruppe admin angeht? Wenn ja, kann ich das irgendwo nachlesen? Wenn nein, warum nicht? Ich jedenfalls kann bisher keine Übereinstimmungen in dieser Frage finden, für mich stellt sich das als ein Sonderweg Apples dar. Und da wüsste ich gerne mal, was und wie andere Unix-Hersteller das sehen, ob die es genauso sehen oder nicht. Hast Du da nähere Info bzw. weitergehende Quellen (auch außerhalb des Apple-Universums), die da mal Licht in die Sache bringen?
0
MacMark
MacMark05.03.0913:37
Die anderen Unices werden nicht hauptsächlich als Desktop-Betriebssystem eingesetzt, sondern als Server. Das OS X-Admin-Konzept würde da nicht viel helfen, da es zu selten zum Tragen käme, weil auf UNIX-Servern relativ selten neue Anwendungs-Programme installiert werden.

Bei einem Desktop-System, auf dem häufig Anwendungs-Programme installiert werden, ist die Admin-Gruppe jedoch sinnvoll, weil sie wie oben beschrieben, die Nutzung von root reduziert.

Bei einem Server erfordert das, was typischerweise installiert wird, so oder so root.

Aus der Ecke eines anderen Desktop-Systems der weiteren UNIX-Familie (GNU/Linux) habe ich gehört, daß denen die Admin-Lösung von OS X ganz gut gefällt.
„@macmark_de“
0
sierkb05.03.0914:07
MacMark
Die anderen Unices werden nicht hauptsächlich als Desktop-Betriebssystem eingesetzt, sondern als Server.

Das Argument finde ich etwas zu schwach. Denn auch dort gibt es in dieser Fragestellung sicher genau dieselben Herausforderungen, und so manches andere klassische Unix wird ebenfalls an der einen oder anderen Stelle auch als Desktop-Unix eingesetzt (ich denke da nur mal an Solaris). Wie regelt Apple das mit seinem MacOSX Server? Will man da zweigleisig fahren, um Deiner herangezogenen Begründung Genüge zu tun -- also einmal die admin-Gruppe favorisieren für den Desktop-Betrieb und einmal die wheel-Gruppe favorisieren für den Server-Betrieb?
Das OS X-Admin-Konzept würde da nicht viel helfen, da es zu selten zum Tragen käme, weil auf UNIX-Servern relativ selten neue Anwendungs-Programme installiert werden.

Ich sehe da eh keinen großen Vorteil drin in diesem Konzept. Es stellt sich mir im Grunde dar wie alter Wein in neuen Schläuchen. Und nicht unbedingt eine echte Verbesserung gegenüber dem Bestehenden. Mir scheint: Hauptsache, mal anders gemacht. Die Frage ist, ob es unterm Strich sinnvoll bzw. mehrheitsfähig ist und auf Dauer Bestand hat/haben kann. Und genau da tun sich bei mir Fragezeichen auf.
Bei einem Desktop-System, auf dem häufig Anwendungs-Programme installiert werden, ist die Admin-Gruppe jedoch sinnvoll, weil sie wie oben beschrieben, die Nutzung von root reduziert.

Genau das wird auch mit der traditionellen Gruppe wheel erreicht.
Aus der Ecke eines anderen Desktop-Systems der weiteren UNIX-Familie (GNU/Linux) habe ich gehört, daß denen die Admin-Lösung von OS X ganz gut gefällt.

Quelle? Wo kann ich drüber lesen? Du meinst jetzt nicht hoffentlich irgendwas in der Richtung aus der Ubuntu-Ecke...
0
MacMark
MacMark05.03.0914:50
Auf Solaris wird nicht alle paar Tage Firefox, Office, Spiel x, etc pp installiert. Daher bringt dort die Admin-Lösung nicht viel.
Daß für solche Situationen mit Admin-Group root vermieden wird, sollte klar sein, oder? Ansonsten lies nochmal weiter oben nach.
„@macmark_de“
0
sierkb05.03.0915:05
MacMark
Auf Solaris wird nicht alle paar Tage Firefox, Office, Spiel x, etc pp installiert. Daher bringt dort die Admin-Lösung nicht viel.

Du weichst meiner Fragestellung aus...
Daß für solche Situationen mit Admin-Group root vermieden wird, sollte klar sein, oder? Ansonsten lies nochmal weiter oben nach.

Du weichst meiner Fragestellung aus...

Wie macht's Apple unter MacOSX Server? Einheitlich? Was wir dort präferiert (admin oder wheel) und mit welcher Begründung?
0
MacMark
MacMark05.03.0915:54
Ziemlich sicher auch Admin. Es nützt beim Server nur nicht ganz so viel wie beim Desktop, weil dort wohl weniger häufig in /Applications und /Library installiert wird.

Da man aber auch hier in /Applications und /Library ändern muß, wäre es unnötiges Risiko, dies als root zu tun. Daher besser mit Admin, denn der hat gerade ausreichende Rechte, root aber zuviele.

Das wird Dir gefallen:

Bei OS X Server empfiehlt Apple, für jeden Admin auch einen Normal-Account zu nutzen und nur wenn nötig den Admin-Account zu verwenden.
Seite 96 "Securing Administrator Accounts" auf
„@macmark_de“
0
sierkb05.03.0916:31
MacMark
Ziemlich sicher auch Admin. Es nützt beim Server nur nicht ganz so viel wie beim Desktop, weil dort wohl weniger häufig in /Applications und /Library installiert wird.

Warum macht Apple das dann auch auf dem Server so, wenn's dort nicht soviel bringen soll? Deine wohlwollende Begründung von oben gegenüber Apple wird spätestens hier jetzt irgendwie ad adsurbum geführt...

Entweder hat etwas Sinn, oder es hat keinen Sinn, und wenn etwas keinen Sinn hat, dann lässt man es weg oder/und macht es anders.
Da man aber auch hier in /Applications und /Library ändern muß, wäre es unnötiges Risiko, dies als root zu tun. Daher besser mit Admin, denn der hat gerade ausreichende Rechte, root aber zuviele.

Das ist alles richtig, und das bestreite ich auch nicht. Weder bisher noch jetzt. Doch wo ist der qualitative Unterschied und der Sicherheitsgewinn in dieser Richtung gegenüber der Gruppe wheel, welche aus genau diesen Gründen unter anderen BSD-Unices ja seit Jahren auch eben die Gruppe der Administratoren ist. Ob jetzt diese administrativen Aufgaben jetzt aus der Gruppe wheel heraus geschehen oder aus der Gruppe admin heraus -- wo ist da der Unterschied? In beiden Fällen haben jeweils deren Mitglieder das Recht, das sudo-Kommando abzusetzen. Nur heißt die Gruppe in dem einen Fall admin und in dem anderen Fall eben wheel.

Und zusätzlich zu alledem wartet das System noch mit ACLs auf, die das Ganze feiner granulieren und weitere Abstufungen zulassen.
kann ja sein, dass Apple meint, durch eine zusätzliche Admin-Gruppe noch zusätzlich Sicherheit zu haben, weil bestimmte wichtige System-Verzeichnisse standardmäßig der Gruppe wheel gehören. Doch weshalb, frage ich mich, ist eine so grundsätzliche und Frage nicht auch schon längst dann in FreeBSD bzw. dem Referenz-System für ein sicheres System, OpenBSD auf gleiche Weise beantwortet worden? Dort stellt man sich solche Fragen doch auch bzw. stellt sich solchen Problemen. Gleichermaßen sowohl für Desktop-Belange als auch für Server-Belange.
Wieso kommt auf einmal Apple und meint, da den Stein der Weisen gefunden zu haben, während das bei den anderen BSDs offenbar nicht so oder anders beantwortet zu werden scheint (von Linux mal ganz zu schweigen)?

Ich sehe da immer noch keine echte überzeugende Begründung für das Vorgehen Apples -- erst recht nicht vor dem Hintergrund, dass ich bisher keine Anhaltspunkte dafür finden kann, dass das bei anderen genauso gedacht und gemacht wird. Und die entsprechenden Hinweise und Quellen, wo ich es evtl. mal nachlesen könnte, wer warum das genauso macht und genauso denkt, willst oder kannst Du mir bisher ja nicht nennen...
Das wird Dir gefallen:

Bei OS X Server empfiehlt Apple, für jeden Admin auch einen Normal-Account zu nutzen und nur wenn nötig den Admin-Account zu verwenden.
Seite 96 "Securing Administrator Accounts" auf

Natürlich gefällt mir das.:-)

Aber im Grunde ist's nichts anderes als bzgl. MacOSX Desktop auch angeraten wird (und eigentlich auch gute, weil verantwortungsbewusste Praxis sein sollte), von Apple leider aber eben so nicht dem normalen Benutzer gegenüber kommuniziert wird. Der normale, durchschnittliche Nutzer arbeitet unter MacOSX mit ziemlich hoher Verbreitung leider standardmäßig als Nutzer mit Admin-Rechten. Anderslautende Hinweise und Ratschläge findet man dann versteckt in solchen Apple Dokumenten (äquivalent dazu die Ausführungen für die Desktop-Variante von MacOSX), die der normale Nutzer unter normalen Umständen weder kennt noch zu Gesicht bekommt.

Mir stellt sich das unterm Strich so dar: gut gemeint, aber auf halbem Wege stehengeblieben bzw. durch andere, nennen wir es mal: Maßnahmen im Sinne der Bequemlichkeit und Popularität, teilweise konterkariert. Und deshalb nur halb so gut und sicher, wie das theoretische und gut gemeinte ursprüngl. Ansinnen.
0
MacMark
MacMark05.03.0918:04
sierkb
… Doch wo ist der qualitative Unterschied und der Sicherheitsgewinn in dieser Richtung gegenüber der Gruppe wheel…

Siehe Posting 05.03.09 08:25
„@macmark_de“
0
_mäuschen
_mäuschen05.03.0918:16


ätzbäz


ze obergurus



häckmäckzäck





_mäuschen ist tot







0
sierkb05.03.0918:18
_mäuschen ist wieder da! Klasse!

Na, was meinst Du zu dem Ganzen, wie ist Deine Meinung dazu?
0
MacMark
MacMark05.03.0918:59
Vielleicht kann _mäuschen das hier besser erklären:

Wenn Du die Admins in die primäre Gruppe von root namens wheel steckst, dann sind sie auf einem Level mit root. Den Admins würden dann per Group-Ownage die Systemdateien gehören!
OS X-Admis stehen unter root. Sie sind nicht in roots Gruppe. Mit ihnen kann man für alle User erreichbare Applikationen installieren, ohne root sein zu müssen.
Root wäre dafür auch Overkill, weil die Programme keine Systemdateien sind.
Normaluser Programme für alle installieren zu lassen, wäre ebenfalls ein Sicherheitsrisiko.
„@macmark_de“
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.