Mailinglist Archive: opensuse-de (5949 mails)
| < Previous | Next > |
Re: verstaendnisfrage: benutzer/gruppen
- From: B.Brodesser@xxxxxxxxxxx (Bernd Brodesser)
- Date: Mon, 1 Oct 2001 10:39:14 +0200
- Message-id: <20011001103913.A2386@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
* 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
> 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
| < Previous | Next > |