Provided by: manpages-de_4.23.1-1_all 
BEZEICHNUNG
attributes - POSIX-Sicherheitskonzepte
BESCHREIBUNG
Hinweis: Der Text dieser Handbuchseite basiert auf Material, das dem Abschnitt »POSIX
Safety Concepts« des GNU-C-Bibliothekshandbuchs entnommen ist. Weitere Details über die
hier beschriebenen Themen können Sie in jenem Handbuch finden.
Verschiedene Funktionshandbuchseiten enthalten einen Abschnitt ATTRIBUTE, der die
Sicherheit beim Aufruf der Funktionen in verschiedenen Kontexten beschreibt. Jener
Abschnitt kommentiert Funktionen mit den folgenden Sicherheitsmarkierungen:
MT-Sicher
MT-Sicher oder Thread-sichere Funktionen können sicher in der Anwesenheit von
anderen Threads aufgerufen werden. Das »MT« in »MT-Sicher« steht für »Multi
Thread«.
MT-Sicher zu sein bedeutet nicht, dass eine Funktion atomar ist noch dass sie die
von POSIX für Benutzer bereitgestellten Speichersynchronisationsmechanismen
verwendet. Es ist sogar möglich, dass der Aufruf von MT-Sicher-Funktionen
nacheinander nicht zu einer MT-Sicher-Kombination führt. Ruft ein Thread
beispielsweise zwei MT-Sicher-Funktionen direkt nacheinander auf, garantiert dies
nicht, dass das Verhalten äquivalent zu einem atomaren Aufruf einer Kombination
beider Funktionen ist, da nebenläufige Aufrufe in anderen Threads diesen Thread
destruktiv beeinflussen können.
Gesamtprogramm-Optimierungen, die über Bibliotheksgrenzen hinweg Inline-Ersetzungen
vornehmen, könnten unsichere Umordnungen offenlegen. Daher wird empfohlen, keine
Inline-Ersetzungen über die GNU-C-Bibliothek-Schnittstelle hinweg vorzunehmen. Der
dokumentierte MT-Sicherheits-Status wird unter Gesamtprogramm-Optimierungen nicht
garantiert. Funktionen, die in Headern definiert sind, die Benutzern zugänglich
sind, wurden allerdings so entworfen, dass sie sicher für Inline-Ersetzungen sind.
MT-Unsicher
MT-Unsicher-Funktionen können nicht sicher in Programmen mit mehreren Threads
aufgerufen werden.
Andere Schlüsselwörter, die in den Sicherheitshinweisen auftauchen, sind in nachfolgenden
Abschnitten definiert.
Bedingt sichere Funktionalitäten
Für einige Funktionalitäten, die Funktionsaufrufe in bestimmten Kontexten unsicher machen,
gibt es bekannte Möglichkeiten, das Sicherheitsproblem zu vermeiden (jenseits vom
kompletten Vermeiden des Funktionsaufrufs). Die nachfolgenden Schlüsselwörter beziehen
sich auf solche Funktionalitäten und jede ihrer Definitionen zeigt an, wie das gesamte
Programm beschränkt werden muss, um dass durch das Schlüsselwort angezeigte
Sicherheitsproblem zu entfernen. Nur wenn alle Gründe, die eine Funktion unsicher machen,
berücksichtigt und durch die dokumentierten Beschränkungen adressiert werden, kann die
Funktion in einem Kontext sicher aufgerufen werden.
init Mit init als MT-Unsicher-Funktionalitäten markierte Funktionen führen beim ersten
Aufruf MT-Unsichere Initialisierungen durch.
Durch mindestens einmaligen Aufruf dieser Funktion in einem Einzel-Thread-Modus
wird dieser bestimmte Grund, aus dem die Funktion als MT-Unsicher betrachtet wird,
entfernt. Falls dafür kein weiterer Grund verbleibt, kann diese Funktion sicher
aufgerufen werden, nachdem andere Threads gestartet wurden.
race Mit race als MT-Sicherheitsproblem kommentierte Funktionen agieren auf Objekten
derart, dass Ressourcenwettläufe auf Daten oder ähnliche Formen desktruktiven
Störens bei nebenläufiger Ausführung ausgelöst werden können. In einigen Fällen
werden die Objekte durch Benutzer an die Funktionen übergeben. In anderen Fällen
werden sie von den Funktionen verwandt, um Werte an Benutzer zurückzugeben. In
wieder anderen werden sie noch nicht mal gegenüber Benutzern offengelegt.
const Mit const als MT-Sicherheitsproblem markierte Funktionen verändern interne Objekte
nicht atomar, die besser als konstant betrachtet werden, da ein wesentlicher Anteil
der GNU-C-Bibliothek auf sie ohne Synchronisierung zugreift. Anders als bei race,
bei dem sowohl schreibende als auch lesende Zugriffe auf interne Objekte als
MT-Unsicher betrachtet werden, gilt diese Markierung nur für schreibende Zugriffe.
Bei schreibenden Zugriffen bleibt der Aufruf MT-Unsicher, aber die
dann-verpflichtende Konstantheit von Objekten, die sie verändern, ermöglicht
MT-Safe lesenden Zugriff (solange kein anderer Grund verbleibt, sie als unsicher zu
betrachten), da das Fehlen von Synchronisierung kein Problem darstellt, wenn die
Objekte tatsächlich konstant sind.
Der Markierung const folgende Kennzeichner taucht selbst als Sicherheitshinweis für
Lesezugriffe auf. Programme, die dieses Sicherheitsproblem umgehen möchten, um
Schreibzugriff durchzuführen, können eine dem Kennzeichner zugeordnete nicht
rekursive Lese-Schreib-Sperre verwenden und alle Aufrufe von mit const gefolgt von
dem Kennzeichner markierten Funktionen mit einer Schreibsperre und alle Aufrufe von
mit dem Kennzeichner selbst markierten Funktionen mit einer Lesesperre absichern.
sig Mit sig als MT-Sicherheitsproblem markierte Funktionen können temporär einen
Signal-Handhaber für interne Zwecke installieren, der mit anderen Verwendungen des
Signals wechselwirkt, die nach einem Doppelpunkt dargestellt sind.
Dieses Sicherheitsproblem kann umgangen werden, indem sichergestellt wird, dass
während der Dauer des Aufrufs keine andere Verwendung dieses Signals stattfindet.
Es wird empfohlen, einen nicht rekursiven Mutex beim Aufruf aller Funktionen, die
das gleiche temporäre Signal verwenden, zu halten und das Signal vor dem Aufruf zu
blockieren und seinen Handhaber danach zurückzusetzen.
term Mit term als MT-Sicherheitsproblem markierte Funktionen können ihre
Terminaleinstellungen auf die empfohlene Art ändern, konkret: tcgetattr(3)
aufrufen, einige Schalter ändern und dann tcsetattr(3) aufrufen. Dadurch entsteht
ein Fenster, in dem einige durch andere Threads vorgenommene Änderungen verloren
gehen. Daher sind mit term markierte Funktionen MT-Unsicher.
Für Anwendungen, die das Terminal verwenden, wird daher empfohlen, nebenläufige
oder wiedereintrittsfähige Interaktionen dadurch zu vermeiden, dass keine
Signal-Handhaber verwandt oder Signale, die es verwenden könnte, blockiert werden
und eine Sperre gehalten wird, während diese Funktionen aufgerufen und mit dem
Terminal interagiert wird. Diese Sperre sollte auch zum gegenseitigen Ausschluss
von mit race:tcattr(dd) markierten Funktionen verwandt werden, wo dd ein
Dateideskriptor für das steuernde Terminal ist. Das aufrufende Programm kann zur
Vereinfachung einen einzelnen Mutex oder einen Mutex pro Terminal verwenden, selbst
wenn die Referenz von verschiedenen Dateideskriptoren kommt.
Andere Sicherheitsbemerkungen
An Funktionen können zusätzliche Schlüsselwörter angehängt werden, die Funktionalitäten
andeuten, die nicht zum unsicheren Aufruf einer Funktion führen, die aber möglicherweise
in bestimmten Klassen von Programmen berücksichtigt werden müssten:
locale Mit locale als MT-Sicherheitsproblem kommentierte Funktionen lesen vom
Locale-Objekt ohne irgendeine Form der Synchronisierung. Werden mit locale
kommentierte Funktionen gleichzeitig zu Locale-Änderungen aufgerufen, könnte sich
deren Verhalten so ändern, dass es nicht den Locale-Werten entspricht, die während
ihrer Ausführung aktiv waren, sondern einer nicht vorhersagbaren Mischung daraus.
Diese Funktionen sind allerdings nicht als MT-Unsicher markiert, da Funktionen, die
das Locale-Objekt verändern, als const:locale markiert sind und als unsicher
betrachtet werden. Da sie unsicher sind, dürfen letztere nicht aufgerufen werden,
wenn mehrere Threads laufen oder asynchrone Signale aktiviert sind, und daher das
Locale-Objekt tatsächlich in diesen Kontexten als konstant betrachtet werden kann,
wodurch erstere sicher sind.
env Mit env als MT-Sicherheitsproblem kommentierte Funktionen greifen auf die Umgebung
mit getenv(3) oder ähnlichem zu, ohne jeglichen Schutz, um Sicherheit in der
Anwesenheit von nebenläufigen Veränderungen sicherzustellen.
Diese Funktionen sind allerdings nicht als MT-Unsicher markiert, da Funktionen, die
die Umgebung verändern, alle mit const:env markiert sind und als unsicher
betrachtet werden. Da sie unsicher sind, dürfen letztere nicht aufgerufen werden,
wenn mehrere Threads laufen oder asynchrone Signale aktiviert sind, und daher die
Umgebung tatsächlich in diesen Kontexten als konstant betrachtet werden können,
wodurch erstere sicher sind.
hostid Mit hostid als MT-Sicherheitsproblem kommentierte Funktionen lesen von systemweiten
Datenstrukturen, die die »Rechnerkennung« der Maschine halten. Diese
Datenstrukturen können im Allgemeinen nicht atomar verändert werden. Da erwartet
wird, dass sich die »Rechnerkennung« im Allgemeinen nicht ändert, wird die daraus
lesende Funktionen (gethostid(3)) als sicher betrachtet, während die verändernde
Funktion (sethostid(3)) als const:hostid markiert ist und damit anzeigt, dass bei
Aufruf besondere Vorsicht walten zu lassen ist. In diesem speziellen Fall erfordert
die besondere Vorsicht eine systemweite (und nicht nur zwischen Prozessen)
Koordination.
sigintr
Mit sigintr als MT-Sicherheitsproblem kommentierte Funktionen greifen auf die
interne Datenstruktur _sigintr der GNU-C-Bibliothek ohne jeglichen Schutz zu, um
Sicherheit beim Auftreten von nebenläufigen Veränderungen sicherzustellen.
Diese Funktionen sind allerdings nicht als MT-Unsicher markiert, da Funktionen, die
diese Datenstruktur verändern, alle mit const:sigintr markiert sind und als
unsicher betrachtet werden. Da sie unsicher sind, dürfen letztere nicht aufgerufen
werden, wenn mehrere Threads laufen oder asynchrone Signale aktiviert sind, und
daher die Datenstruktur tatsächlich in diesen Kontexten als konstant betrachtet
werden kann, wodurch erstere sicher sind.
cwd Mit cwd als MT-Sicherheitsproblem kommentierte Funktionen können temporär während
ihrer Ausführung ihr aktuelles Arbeitsverzeichnis ändern, wodurch relative
Pfadnamen in anderen Threads oder innerhalb asynchroner Signal- oder
Abbruch-Handhaber auf unvorhergesehene Weise aufgelöst werden könnten.
Dies ist kein ausreichender Grund, die so markierten Funktionen als MT-Unsicher zu
markieren, aber wenn dieses Verhalten optional ist (z.B. nftw(3) mit FTW_CHDIR)
könnte das Vermeiden dieser Option eine gute Alternative zur Verwendung
vollständiger Pfadnamen oder Systemaufrufen mit relativen Dateideskriptoren (z.B.
openat(2)) sein.
:Kennzeichner
Funktionen können manchmal Kennzeichner folgen, die zum Gruppieren mehrerer
Funktionen gedacht sind, die beispielsweise auf Datenstrukturen auf eine unsichere
Art zugreifen, wie bei race und const, oder um genauere Informationen wie die
Benennung von Signalen in einer mit sig markierten Funktion bereitzustellen. Es
wird angedacht, dies in der Zukunft auf lock und corrupt anzuwenden.
In den meisten Fällen wird der Kennzeichner eine Gruppe von Funktionen benennen, er
kann aber auch globale Objekte oder Funktionsargumente benennen oder
identifizierbare Eigenschaften oder ihnen zugeordnete logische Komponenten. Eine
Darstellung kann beispielsweise :buf(arg) zur Bezeichnung eines einem Argumenten
arg zugeordneten Puffers oder :tcattr(fd) zur Bezeichnung der Terminalattribute
eines Dateideskriptors dd sein.
Die häufigste Verwendung von Kennzeichnern ist die Bereitstellung logischer Gruppen
von Funktionen und Argumenten, die durch die gleichen Synchronisationsprimitiven
geschützt werden müssen, um eine sichere Aktion in einem gegebenen Kontext
sicherzustellen.
/Bedingung
Einige Sicherheitsanmerkungen können von Bedingungen abhängen. Sie gelten nur,
falls ein logischer Ausdruck, der Argumente, globale Variablen oder sogar den
zugrunde liegenden Kernel als wahr ausgewertet werden kann. Beispielsweise zeigen
/!ps und /one_per_line an, dass die vorhergehende Markierung nur gilt, wenn das
Argument ps NULL oder die globale Variable one_per_line von Null verschieden ist.
Wenn alle Markierungen, die eine Funktion unsicher werden lassen, mit solchen
Bedingungen verziert sind und keine der benannten Bedingungen zutrifft, dann kann
diese Funktion als sicher betrachtet werden.
SIEHE AUCH
pthreads(7), signal-safety(7)
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
<debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-
Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
Mail an die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.