Am Sun, 30 Sep 2001 schrieb suse-linux:

bei linux ist mir dass irgendwie nciht klar wie das gehen soll. ich möchte einen benutzer (zb klaus/users) in einem verzeichnis schreibrechte geben (/usr/local/httpd) damit klaus direkt via samba seine html dokumente in das serverroot einspielen kann aber sonst möchte ich keinem anderen benutzer dieses schreibrecht geben. wie geh ich da vor (write by others passt mir nciht) und root/root sollte ich vemrutlich nciht ändern da sonst ev das system probleme bekommt. beim hizufügen von klaus zur gruppe root gibts auch eine meldung, die ich nciht ganz verstehe (user wird einer gruppe unter id 100 zugewiesen)

wie löst das der linux-profi?

Zunächst mal sind Unix-Rechte nicht ganz so universell, man kann nicht alle Konstellationen darstellen, die auch mit Windows-Rechten gehen. Für die Praxis reichts aber in der Regel. In diesem Speziellen Fall macht man das am besten über die Gruppenrechte. Also neue Gruppe anlegen, die Datei oder das Verzeichnis auf g+rw[x] setzen und der Gruppe übereignen, danach alle User die zugreifen müssen in die Gruppe aufnehmen. -- MfG, Erhard Schwenk

nur damit ichs richtig verstehe: jetzt gehört das verzeichnis dem benutzer root der gruppe root.

damit das system weiterläuft, darf ich da das verzeichnis der neuen gruppe "webdesign" zuordnen in der nun klaus ist?

das System sollte auch nach dieser Änderung weiterlaufen. Falls es Probleme gibt (was ich mir nicht vorstellen kann) einfach chown root.root verzeichnis und du hast den Ursprungszustand wieder da und dann gehts auf jeden Fall wieder

kann ich denn die gruppe root in die gruppe webdesign aufnehmen oder kann ich das so nciht kombinieren. ich möchte dass apache weiter funktioniert.

ich glaube Gruppen in Gruppen einzubinden geht nicht (direkt). Natürlich könnte man sich ein Script schreiben, daß alle User der Gruppe A in die Gruppe B aufnimmt.

kann sein dass das was ich möchte in diesem fall nciht möglich ist?

evtl. nicht über den Weg, den du dir vorstellst.

gruss marius

-- tschau fisch http://www.edv-leisnig.de http://www.profiseller.de/shop/edv

* Heiner Lamprecht schrieb am 30.Sep.2001:

Am Sonntag, 30. September 2001 22:27 schrieb suse-linux:

...

nur damit ichs richtig verstehe: jetzt gehört das verzeichnis dem benutzer root der gruppe root.

...

damit das system weiterläuft, darf ich da das verzeichnis der neuen gruppe "webdesign" zuordnen in der nun klaus ist?

Der Benutzer root ist der Superuser, der darf so wie so alles. Der kümmert sich nicht um Rechte.

Damit das System weiterläuft, muss der Webserver (sprich apache) die Webseiten lesen dürfen. Der apache läuft _nicht_ als Nutzer root, sondern als Nutzer wwwrun (wwwrun:nogroup). Also schon jetzt gehört das Verzeichnis gar nicht dem apache.

Wie gesagt, root darf so wie so alles.

...

kann ich denn die gruppe root in die gruppe webdesign aufnehmen oder kann ich das so nciht kombinieren.

In der Gruppe root sollte nur der Superuser also root sein, sonst niemand.

Direkt: Nein. Gruppen können nicht "verschachtelt" werden. Das ist aber für Dein Problem auch gar nicht nötig.

Es ist aber möglich, daß ein User mehere Gruppen angehört. Wenn z.B alle User die der Gruppe B angehören auch der Gruppe A angehören, so ist es so, als wenn die Gruppe B in der Gruppe A liegt.

...

ich möchte dass apache weiter funktioniert.

Probiers doch aus. Ich fasse mal kurz zusammen: Jede Datei/Verzeichniss/Gerätedatei/Pipe gehört jemanden und gehört auch zu genau einer Gruppe. Dies wird über Nummern den sogenannten UID und GID geregelt. Die UID und GID stehen in der I-Node der jeweiligen Datei, nicht die Klarnamen der User bzw. Gruppe. Jeder User hat genau ein UID und ein primärer GID, kann aber zu quasi[1] beliebig vielen Gruppen mit dem jeweiligen GID gehören. UID und GID der primären Gruppe sind in der /etc/passwd eingetragen, den anderen Gruppen wird der jeweilige User in der /etc/group zugeordnet. Es gibt einen besonderen User, den sogenannten Superuser, er ist dadurch gekennzeichnet, daß er den UID 0 hat. Meist heißt er root. Aber das ist nicht entscheident, entscheident ist der UID[*]. Es kann sein, daß mehere User den gleichen UID haben, dann aber sind es nicht mehere User mit dem gleichen UID, sondern ein User mit mehere Namen.[2] Denn überall, außerhalb von /etc/passwd, /etc/group und /etc/shadow wird nur mit dem UID und nicht mit dem Klarnamen gearbeitet. Programme, die den Klarnamen des Users ausgeben, wie etwa who, vi oder ls -l schauen vorher in der /etc/passwd bzw. /etc/group nach, dort nehmen sie den erstbesten Namen, der zu dem UID paßt. Auch jeder Prozeß ist genau einem User und einer Gruppe zugeordnet. Auch in der Prozeßtabelle stehen UID und GID, nicht etwa Klarnamen. Wenn sich ein User einloggt, dann erhält er eine shell, mit deren Hilfe er interaktiv aggieren kann. Die Frage, was ein User darf, reduziert sich mithin auf die Frage, was ein Prozeß darf, und was nicht. Jede Datei hat drei Schreib-, drei Lese- und drei Ausführungsbits. Und zwar jeweils eins für den Dateibesitzer, eins für die Gruppe und eins für alle anderen. Darüberhinaus hat noch jede Datei ein SUID-Bit, ein SGID-Bit und ein Sticky-Bit. Diese zwölf Bits, stecken zusammen mit weiteren vier Bits, die den Dateityp (eigentliche Datei, Verzeichniß, symbolischer Link, named Pipe, Socket, Blockorientierte Gerätedate oder Zeichenorientierte Gerätedatei) festlegen, im zwei Byte breiten Dateimodus, der wiederum in der I-Node der Datei steckt. Stimmen der UID des Prozesses und der der Datei überein, mit anderen Worten, ist der Besitzer des Prozesses auch der Besitzer der Datei, so werden nur, und ausschließlich die Rechte des Besitzers überprüft, nicht aber die anderen Rechte. So ist es z.B völlig irrelevant, ob der GID des Prozesses und die der Datei übereinstimmen oder nicht. Wenn Der Besitzer nicht schreiben darf, dann ist es völlig irrelevant, ob ein Gruppenmitglied schreiben darf, oder alle anderen. Der Besitzer darf es halt nicht, auch wenn alle anderen es dürfen. Stimmen der UID des Prozesses und die der Datei nicht überein, so wird überprüft, ob der Prozeß zu der Gruppe der Datei gehört. Dies ist zum einen der Fall, wenn der GID des Prozesses mit dem der Datei übereinstimmt, und zum anderen, wenn der Besitzer zu der Gruppe der Datei gehört. Wenn dem so ist, dann sind die Gruppenrechte relevant, und ausschließlich diese. Da es hier entscheidend ist, nochmal mit anderen Worten: Die Gruppenrechte werden relevant, wenn erstens der Besitzer des Prozesses und der Besitzer der Datei verschieden sind _und_ wenn zweitens der Prozeß zu der Gruppe der Datei gehört. Der Prozeß gehört zu der Gruppe der Datei, wenn der GID des Prozesses mit dem GID der Datei übereinstimmt, _oder_ wenn der GID der Datei in der /etc/group dem Besitzer des Prozesses zugeordnet ist[3]. Die umgekehrte Überprüfung, ob der Besitzer der Datei und die GID des Prozesses in der /etc/group einander zugeordnet sind, findet nicht statt. Wenn Prozeß und Datei weder die gleiche UID noch der Prozeß zu der Gruppe der Datei gehört, dann sind die Rechte der anderen relevant. Es ist immer eine, und nur eine Gruppe von Rechten relevant. Also entweder die des Besitzers, oder die der Gruppe oder die der anderen. Es ist durchaus möglich, die Rechte so zu gestalten, daß alle schreiben und lesen dürfen, nur die Gruppenmitglieder nicht schreiben und der Besitzer weder schreiben noch lesen. Wenn dem so ist, so nützt es dem Besitzer nichts, wenn er auch Gruppenmitglied ist, er darf nicht lesen. Ob diese Einstellung sinnvoll ist, ist eine andere Frage. Eine andere wenig Sinnvolle, aber doch mögliche Einstellung ist es, wenn einer auf eine Datei schreiben, aber nicht lesen darf. [4] Beim Superuser werden die Rechte nicht abgefragt, er darf alles. Es kann natürlich sein, daß der Prozeß selber überprüft, ob er dem Superuser gehört, also ob er den UID 0 hat und beendet sich gegebenenfalls dann selber. Dies macht für den Außenstehenden den Eindruck, daß der Superuser doch nicht alles darf. Aber das macht der Prozeß selber und nicht der Kernel. Einzige Ausnahme, eine Datei, die für niemanden ausführbar ist, also weder für den Besitzer, noch für die Gruppe, noch für alle anderen, ist eine nicht ausführbare Datei und somit auch für den Superuser nicht ausführbar. Ein Prozeß, der an einer Datei was anfügen, verändern oder löschen möchte, der braucht die Schreibrechte der Datei. Wenn ein Prozeß etwas aus einer Datei lesen möchte, so braucht er das Leserecht. Wenn ein Prozeß aber die Datei löschen will, so braucht er dazu *nicht* das Schreib-, oder ein anderes Recht der Datei dazu. Er braucht dazu lediglich das Schreibrecht des Verzeichnisses in der die Datei steht, denn das Verzeichniß wird ja verändert. Genauer: Ein Prozeß kann nur ein Hardlink auf die Datei wegnehmen. Wenn eine Datei kein Hardlink mehr hat, der auf ihr zeigt, dann wird sie zur Überschreibung freigegeben, es kann mit normalen Mitteln nicht mehr auf sie zugegriffen werden. [5] Ist eine Datei ein ausführbares Programm, und hat ein Prozeß die Ausführungrechte auf diese Datei, so kann der Prozeß diese Datei ausführen. Das macht er, indem er sich selber mit der Datei überschreibt. Ist das SUID-Bit der Datei gesetzt, so übernimmt der Prozeß den UID der Datei, ansonsten behält er seine alte UID.[6] Ist das SGID-Bit der Datei gesetzt, so übernimmt der Prozeß den GID der Datei, ansonsten behält er seine alte GID[6]. Dies gilt für ausführbare Programme, nicht für Skripte, denn mit den Skripten kann der Prozessor nichts anfangen. Dafür bedarf es einen Interpreter. Welcher benötigt wird, sollte in der ersten Zeile stehn, etwa #! /bin/bash. Damit der Interpreter die Datei interpretieren kann, benötigt er das Leserecht. Ein Skript kann somit nur ausgeführt werden wenn der Prozeß sowohl Ausführ- wie auch Leserecht hat.[7] Bei Verzeichnissen haben die Ausführungsrechte eine etwas andere Bedeutung. Nur ein Prozeß, der die Ausführungsrechte eines Verzeichnisses hat, kann dieses Verzeichniß zum Arbeitsverzeichniß machen. Und nur wenn er die Ausführungsrechte eines Verzeichnißes hat, kann er in ihm weiterverfolgen. Das heißt, wenn ein Prozeß in einer Pfadangabe das Ausführungrecht für irgend ein Verzeichniß in diesem Pfad nicht hat, wird das Ansinnen scheitern. Die Rechte kann nur der Besitzer oder der Superuser ändern, unabhängig von den Rechten selber. Auch wenn der Besitzer weder Schreib-, noch Lese-, noch Ausführungsrecht auf die Datei hat, so kann er dies ändern und somit an den jeweiligen Rechten gelangen. Der Besitzer, kann die Gruppe eine Datei verändern, wenn er selber zu der neuen Gruppe gehört. Zu der alten Gruppe muß er nicht gehören. Der Superuser kann sowohl Besitzer als auch Gruppe jeder Datei nach belieben verändern. Den Besitzer einer Datei kann nur der Superuser verändern. [1] Ist natürlich, wie alles, irgendwie begrenzt. Aber sehr, sehr viele Gruppen sind möglich. [2] Ist beim Superuser beliebt, aber ehr von abzuraten. Aber immer noch besser, als wenn es nur ein root gibt, aber mehere Leute das zugehörige Paßwort kennen. [3] In der /etc/group stehen der Klarname der Gruppe, die zugehörige GID (beides wird einander hier zugeordnet) und die Klarnamen der Besitzer. Hat ein Besitzer mehere Namen, so kann es an dieser Stelle zu unterschiedlichem Verhalten kommen. Ich kann mir vorstellen, daß sich verschiedene UNIX sich hier verschieden verhalten. [4] Allerdings so sinnentlehrt kann es nicht sein, da genau dies bei /dev/tty* so verwirklicht ist. Was hier auch einen Sinn ergibt, da ein anderes Gruppenmitglied einem auf dem Bildschirm schreiben können soll, aber nicht lesen können soll. [5] Über das direkte lesen der Festplattendevice (/dev/hda1, /dev/sdb3, ...) kann man doch noch an die Daten kommen. Ist zum Retten normalerweise viel zu aufwendig, aber wenn man supergeheime Daten hat und einen Geheimdienst mit unheimlich viel Manpower gegen sich, so ist ein einfaches Löschen der supergeheimen Dateien nicht das Mittel der Wahl. [6] Genauer werden effektiver UID, bzw. effektiver GID überschrieben, während der sogenannte reale UID bzw. reale GID, die ein Prozeß auch noch hat, erhalten bleiben. Wenn oben irgendwo UID bzw. GID im Bezug zu Prozessen erwähnt wurde, so ist immer der effektive UID bzw. effektive GID gemeint. Lediglich bei der Abfrage des Prozesses an sich selber, ob er Superuser, oder auch irgend ein anderer User ist, da kann auch der reale UID, bzw. reale GID herangezogen werden. Der Kernel interessiert sich weiter nicht dafür, er schleppt sie nur mit sich rum und ändert sie nur bei bestimmten Systembefehlen. Bei Linux gibt es sogar noch einen weiteren UID bzw. GID. Aber für alles oben genannte ist nur der effektive UID, bzw. effektive GID von Belang. Dateien haben nur einen UID und einen GID. [7] Wird das #!... nicht angegeben und der aufrufende Prozeß ist ein Interpreter, etwa eine shell, so interpretiert dieser in der Regel das skript selber aus. Kann natürlich in die Hose gehen, wenn das Skript eine andere shell als Aufrufer erwartet. Wird das Skript über ein Interpreter aufgerufen, etwa bei dem Aufruf bash skript, so braucht es keine Ausführungs-, wohl aber Leserechte. Ist man in einer shell, so führt sie bei . skript dieses aus. Hier ist ebenfalls nur das Lese-, nicht aber das Ausführungrecht gefragt. [*] Der UID und der GID kommt mir zwar was merkwürdig vor, aber es heißt der Identifizierer. Bernd -- Welches Buch ist zu empfehlen? Schon mal bei SuSE vorbeigesehen? http://www.suse.de/de/produkte/buecher/index.html oder die Empfehlungen der SuSE-Entwickler auf dem eigenen Rechner? file:///usr/shar/doc/sdb/de/html/literatur.html |Zufallssignatur 5