<Zurück | Inhalte | Weiter>

Das -u und -a Optionen geben zusätzliche Informationen. Weitere Optionen und ihre Funktionsweise finden Sie auf den Infoseiten.

Im nächsten Abschnitt werden wir sehen, wie ein Prozess einen anderen erzeugen kann.

4.1.5. Leben und Tod eines Prozesses

4.1.5.1. Prozesserstellung

Ein neuer Prozess wird erstellt, weil ein bestehender Prozess eine exakte Kopie von sich selbst erstellt. Dieser untergeordnete Prozess hat dieselbe Umgebung wie sein übergeordneter Prozess, nur die Prozess-ID-Nummer ist unterschiedlich. Dieses Verfahren heißt gabeln.

Nach dem Forking-Vorgang wird der Adressraum des Kindprozesses mit den neuen Prozessdaten überschrieben. Dies geschieht durch eine exec Aufruf an das System.

Das fork-and-exec Der Mechanismus tauscht somit einen alten Befehl gegen einen neuen aus, während die Umgebung, in der das neue Programm ausgeführt wird, dieselbe bleibt, einschließlich der Konfiguration von Eingabe- und Ausgabegeräten, Umgebungsvariablen und Priorität. Dieser Mechanismus wird zur Erstellung aller UNIX-Prozesse verwendet und gilt daher auch für das Linux-Betriebssystem. Schon der erste Prozess, init, mit der Prozess-ID 1, wird während des Bootvorgangs im geforkt

sogenannt Bootstrapping Verfahren.

Dieses Schema veranschaulicht den Fork-and-Exec-Mechanismus. Die Prozess-ID ändert sich nach dem Fork-Vorgang:

Abbildung 4-1. Fork-and-Exec-Mechanismus

Es gibt einige Fälle, in denen init wird zum übergeordneten Element eines Prozesses, obwohl der Prozess nicht von gestartet wurde init, wie wir bereits im gesehen haben PStree Beispiel. Viele Programme, z.B. dämonisieren ihre untergeordneten Prozesse, sodass sie weiterlaufen können, wenn der übergeordnete Prozess stoppt oder gestoppt wird. Ein typisches Beispiel ist ein Fenstermanager; es beginnt ein Xterm Prozess, der eine Shell generiert, die Befehle akzeptiert. Der Fenstermanager lehnt dann jede weitere Verantwortung ab und übergibt den untergeordneten Prozess an init. Mithilfe dieses Mechanismus ist es möglich, Fenstermanager zu ändern, ohne laufende Anwendungen zu unterbrechen.

Hin und wieder geht etwas schief, auch in guten Familien. In Ausnahmefällen kann es vorkommen, dass ein Prozess beendet wird, während der übergeordnete Prozess nicht auf den Abschluss dieses Prozesses wartet. Ein solcher unbegrabener Prozess wird als a bezeichnet Zombie verarbeiten.

4.1.5.2. Prozesse beenden

Wenn ein Prozess normal endet (er wird nicht abgebrochen oder anderweitig unerwartet unterbrochen), gibt das Programm seine zurück Exit-Status an die Eltern. Dieser Exit-Status ist eine vom Programm zurückgegebene Zahl, die die Ergebnisse der Programmausführung liefert. Das System zur Rückgabe von Informationen bei der Ausführung eines Jobs hat seinen Ursprung in der Programmiersprache C, in der UNIX geschrieben wurde.

Die Rückkehrcodes können dann vom übergeordneten Element oder in Skripten interpretiert werden. Die Werte der Returncodes sind programmspezifisch. Diese Informationen finden Sie normalerweise in den Manpages des angegebenen Programms, beispielsweise in der grep Der Befehl kehrt zurück -1 Wenn keine Übereinstimmungen gefunden werden, kann eine Meldung wie „Keine Dateien gefunden“ ausgegeben werden. Ein weiteres Beispiel ist der integrierte Bash-Befehl was immer dies auch sein sollte., was nichts anderes tut, als einen Exit-Status von 0 zurückzugeben, was Erfolg bedeutet.

4.1.5.3. Signale

Prozesse werden beendet, weil sie ein Signal empfangen. Es gibt mehrere Signale, die Sie an einen Prozess senden können. Benutzen Sie die töten Befehl zum Senden eines Signals an einen Prozess. Der Befehl töten -l zeigt eine Liste von Signalen. Die meisten Signale sind für die interne Verwendung durch das System oder für Programmierer beim Schreiben von Code bestimmt. Als Benutzer benötigen Sie folgende Signale:

Tabelle 4-2. Gemeinsame Signale

Weitere Informationen zu Standardaktionen, die beim Senden eines Signals an einen Prozess ausgeführt werden, finden Sie unter Mann 7 Signal.

4.1.6. SUID und SGID

Wie im vorherigen Kapitel versprochen, gehen wir nun näher auf die Sondermodi SUID und SGID ein. Diese Modi sollen normalen Benutzern die Möglichkeit geben, Aufgaben auszuführen, die sie aufgrund des strengen Dateiberechtigungsschemas, das auf UNIX-basierten Systemen verwendet wird, normalerweise nicht ausführen könnten. Im Idealfall werden Sondermodi möglichst sparsam eingesetzt, da sie Sicherheitsrisiken bergen. Linux-Entwickler haben im Allgemeinen versucht, sie so weit wie möglich zu vermeiden. Das Linux ps Die Version verwendet beispielsweise die in der gespeicherten Informationen / proc Dateisystem, das für jedermann zugänglich ist, wodurch vermieden wird, dass sensible Systemdaten und -ressourcen der Öffentlichkeit zugänglich gemacht werden. Davor und noch auf älteren UNIX-Systemen war die ps Das Programm benötigte Zugriff auf Dateien wie z / dev / mem und / dev / kmem, was aufgrund der Berechtigungen und Eigentumsrechte für diese Dateien Nachteile hatte:

Mit älteren Versionen von pswar es nicht möglich, das Programm als normaler Benutzer zu starten, es sei denn, es wurden spezielle Modi darauf angewendet.

Während wir im Allgemeinen versuchen, die Anwendung spezieller Modi zu vermeiden, ist es manchmal notwendig, eine SUID zu verwenden. Ein Beispiel ist der Mechanismus zum Ändern von Passwörtern. Natürlich möchten Benutzer dies selbst tun, anstatt ihr Passwort vom Systemadministrator festlegen zu lassen. Wie wir wissen, sind Benutzernamen und Passwörter im aufgeführt / etc / passwd Datei, die über diese Zugriffsberechtigungen und Eigentümer verfügt:

bea:~> ls -l /etc/passwd

-rw-r--r-- 1 Wurzel Wurzel

1267 16. Januar 14:43 /etc/passwd

bea:~> ls -l /etc/passwd

-rw-r--r-- 1 Wurzel Wurzel

Dennoch müssen Benutzer in der Lage sein, ihre eigenen Informationen in dieser Datei zu ändern. Dies wird durch die Angabe erreicht passwd

Sonderberechtigungen für das Programm:

mia:~> welches Passwort

passwd ist /usr/bin/passwd

mia:~> welches Passwort

passwd ist /usr/bin/passwd

mia:~> ls -l / usr / bin / passwd

-rs--x--x 1 Wurzel Wurzel

13476 7. August 06:03 /usr/bin/passwd*

mia:~> ls -l / usr / bin / passwd

-rs--x--x 1 Wurzel Wurzel

Bei Aufruf wird die passwd Der Befehl wird mit den Zugriffsberechtigungen von ausgeführt WurzelDadurch kann ein normaler Benutzer die Kennwortdatei bearbeiten, deren Eigentümer der Systemadministrator ist.

SGID-Modi in einer Datei kommen nicht annähernd so häufig vor wie SUID, da SGID häufig die Erstellung zusätzlicher Gruppen erfordert. In einigen Fällen müssen wir uns jedoch diese Mühe machen, um eine elegante Lösung zu erstellen (machen Sie sich darüber keine allzu großen Sorgen – die erforderlichen Gruppen werden normalerweise bei der Installation erstellt). Dies ist der Fall für schreiben und wall Programme, mit denen Nachrichten an Endgeräte anderer Benutzer gesendet werden (TTYS). Der schreiben Der Befehl schreibt eine Nachricht an einen einzelnen Benutzer wall schreibt an alle verbundenen Benutzer.

Das Senden von Text an das Terminal oder die grafische Anzeige eines anderen Benutzers ist normalerweise nicht zulässig. Um dieses Problem zu umgehen, wurde eine Gruppe erstellt, die alle Endgeräte besitzt. Wenn das schreiben und wall Befehlen werden SGID-Berechtigungen gewährt, die Befehle werden mit den Zugriffsrechten ausgeführt, die für diese Gruppe gelten. tty im Beispiel. Da diese Gruppe Schreibzugriff auf das Zielterminal hat, kann auch ein Benutzer, der keine Berechtigung zur Nutzung dieses Terminals hat, Nachrichten an dieses senden.

Im Beispiel unten: Benutzer joe Ermittelt zunächst, mit welchem ​​Endgerät sein Gesprächspartner verbunden ist die Befehl. Dann schickt er ihr eine Nachricht über das schreiben Befehl. Ebenfalls dargestellt sind die Zugriffsrechte auf schreiben Programm und auf den vom empfangenden Benutzer belegten Terminals: Es ist klar, dass andere als der Benutzerbesitzer keine Berechtigungen auf dem Gerät haben, mit Ausnahme des Gruppenbesitzers, der darauf schreiben kann.

joe:~> die schreiben

schreiben ist /usr/bin/write

joe:~> ls -l /usr/bin/write

-rwxr-sr-x 1 Root-TTY

8744 5. Dezember 00:55 /usr/bin/write*

joe:~> die schreiben

schreiben ist /usr/bin/write

joe:~> ls -l /usr/bin/write

-rwxr-sr-x 1 Root-TTY

joe:~> die

Jenny tty1

Jenny Punkte/1

Jenny Punkte/2

Jenny Punkte/3

Joe Punkte/0

23. Januar 11:41

23. Januar 12:21 (:0)

23. Januar 12:22 (:0)

23. Januar 12:22 (:0)

20. Januar 10:13 (lo.callhost.org)

joe:~> die

Jenny tty1

Jenny Punkte/1

Jenny Punkte/2

Jenny Punkte/3

Joe Punkte/0

joe:~> ls -l /dev/tty1

crw--w---- 1 Jenny Tty 4,

1. 23. Januar 11:41 /dev/tty1

joe:~> ls -l /dev/tty1

crw--w---- 1 Jenny Tty 4,

joe:~> schreibe Jenny tty1

Hey Jenny, sollen wir zusammen zu Mittag essen?

^C

joe:~> schreibe Jenny tty1

Hey Jenny, sollen wir zusammen zu Mittag essen?

^C

Mitglied jenny bekommt das auf ihrem Bildschirm:

Nachricht von [E-Mail geschützt] auf Ptys/1 um 12:36 ... Hey Jenny, sollen wir zusammen zu Mittag essen?

EOF

Nachricht von [E-Mail geschützt] auf Ptys/1 um 12:36 ... Hey Jenny, sollen wir zusammen zu Mittag essen?

EOF

Nach Erhalt einer Nachricht kann das Terminal über die gelöscht werden Ctrl+L Tastenkombination. Um überhaupt keine Nachrichten zu erhalten (außer vom Systemadministrator), verwenden Sie die mesg Befehl. Um zu sehen, welche verbundenen Benutzer Nachrichten von anderen akzeptieren, verwenden Sie die -w. Alle Funktionen werden auf den Infoseiten jedes Befehls ausführlich erklärt.

Gruppennamen können variieren

Das Gruppenschema ist verteilungsspezifisch. Andere Distributionen verwenden möglicherweise andere Namen oder andere Lösungen.

<Zurück | Inhalte | Weiter>