Attribute(7) Miscellaneous Information Manual Attribute(7) 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 uber die hier beschriebenen Themen konnen 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 konnen sicher in der Anwesenheit von anderen Threads aufgerufen werden. Das >>MT<< in >>MT-Sicher<< steht fur >>Multi Thread<<. MT-Sicher zu sein bedeutet nicht, dass eine Funktion atomar ist noch dass sie die von POSIX fur Benutzer bereitgestellten Speichersynchronisationsmechanismen verwendet. Es ist sogar moglich, dass der Aufruf von MT-Sicher-Funktionen nacheinander nicht zu einer MT-Sicher-Kombination fuhrt. Ruft ein Thread beispielsweise zwei MT-Sicher-Funktionen direkt nacheinander auf, garantiert dies nicht, dass das Verhalten aquivalent zu einem atomaren Aufruf einer Kombination beider Funktionen ist, da nebenlaufige Aufrufe in anderen Threads diesen Thread destruktiv beeinflussen konnen. Gesamtprogramm-Optimierungen, die uber Bibliotheksgrenzen hinweg Inline-Ersetzungen vornehmen, konnten unsichere Umordnungen offenlegen. Daher wird empfohlen, keine Inline-Ersetzungen uber 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 zuganglich sind, wurden allerdings so entworfen, dass sie sicher fur Inline-Ersetzungen sind. MT-Unsicher MT-Unsicher-Funktionen konnen nicht sicher in Programmen mit mehreren Threads aufgerufen werden. Andere Schlusselworter, die in den Sicherheitshinweisen auftauchen, sind in nachfolgenden Abschnitten definiert. Bedingt sichere Funktionalitaten Fur einige Funktionalitaten, die Funktionsaufrufe in bestimmten Kontexten unsicher machen, gibt es bekannte Moglichkeiten, das Sicherheitsproblem zu vermeiden (jenseits vom kompletten Vermeiden des Funktionsaufrufs). Die nachfolgenden Schlusselworter beziehen sich auf solche Funktionalitaten und jede ihrer Definitionen zeigt an, wie das gesamte Programm beschrankt werden muss, um dass durch das Schlusselwort angezeigte Sicherheitsproblem zu entfernen. Nur wenn alle Grunde, die eine Funktion unsicher machen, berucksichtigt und durch die dokumentierten Beschrankungen adressiert werden, kann die Funktion in einem Kontext sicher aufgerufen werden. init Mit init als MT-Unsicher-Funktionalitaten markierte Funktionen fuhren 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 dafur 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 Ressourcenwettlaufe auf Daten oder ahnliche Formen desktruktiven Storens bei nebenlaufiger Ausfuhrung ausgelost werden konnen. In einigen Fallen werden die Objekte durch Benutzer an die Funktionen ubergeben. In anderen Fallen werden sie von den Funktionen verwandt, um Werte an Benutzer zuruckzugeben. In wieder anderen werden sie noch nicht mal gegenuber Benutzern offengelegt. const Mit const als MT-Sicherheitsproblem markierte Funktionen verandern 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 fur schreibende Zugriffe. Bei schreibenden Zugriffen bleibt der Aufruf MT-Unsicher, aber die dann-verpflichtende Konstantheit von Objekten, die sie verandern, ermoglicht 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 tatsachlich konstant sind. Der Markierung const folgende Kennzeichner taucht selbst als Sicherheitshinweis fur Lesezugriffe auf. Programme, die dieses Sicherheitsproblem umgehen mochten, um Schreibzugriff durchzufuhren, konnen 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 konnen temporar einen Signal-Handhaber fur 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 wahrend der Dauer des Aufrufs keine andere Verwendung dieses Signals stattfindet. Es wird empfohlen, einen nicht rekursiven Mutex beim Aufruf aller Funktionen, die das gleiche temporare Signal verwenden, zu halten und das Signal vor dem Aufruf zu blockieren und seinen Handhaber danach zuruckzusetzen. term Mit term als MT-Sicherheitsproblem markierte Funktionen konnen ihre Terminaleinstellungen auf die empfohlene Art andern, konkret: tcgetattr(3) aufrufen, einige Schalter andern und dann tcsetattr(3) aufrufen. Dadurch entsteht ein Fenster, in dem einige durch andere Threads vorgenommene Anderungen verloren gehen. Daher sind mit term markierte Funktionen MT-Unsicher. Fur Anwendungen, die das Terminal verwenden, wird daher empfohlen, nebenlaufige oder wiedereintrittsfahige Interaktionen dadurch zu vermeiden, dass keine Signal-Handhaber verwandt oder Signale, die es verwenden konnte, blockiert werden und eine Sperre gehalten wird, wahrend 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 fur 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 konnen zusatzliche Schlusselworter angehangt werden, die Funktionalitaten andeuten, die nicht zum unsicheren Aufruf einer Funktion fuhren, die aber moglicherweise in bestimmten Klassen von Programmen berucksichtigt werden mussten: 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-Anderungen aufgerufen, konnte sich deren Verhalten so andern, dass es nicht den Locale-Werten entspricht, die wahrend ihrer Ausfuhrung aktiv waren, sondern einer nicht vorhersagbaren Mischung daraus. Diese Funktionen sind allerdings nicht als MT-Unsicher markiert, da Funktionen, die das Locale-Objekt verandern, als const:locale markiert sind und als unsicher betrachtet werden. Da sie unsicher sind, durfen letztere nicht aufgerufen werden, wenn mehrere Threads laufen oder asynchrone Signale aktiviert sind, und daher das Locale-Objekt tatsachlich 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 ahnlichem zu, ohne jeglichen Schutz, um Sicherheit in der Anwesenheit von nebenlaufigen Veranderungen sicherzustellen. Diese Funktionen sind allerdings nicht als MT-Unsicher markiert, da Funktionen, die die Umgebung verandern, alle mit const:env markiert sind und als unsicher betrachtet werden. Da sie unsicher sind, durfen letztere nicht aufgerufen werden, wenn mehrere Threads laufen oder asynchrone Signale aktiviert sind, und daher die Umgebung tatsachlich in diesen Kontexten als konstant betrachtet werden konnen, wodurch erstere sicher sind. hostid Mit hostid als MT-Sicherheitsproblem kommentierte Funktionen lesen von systemweiten Datenstrukturen, die die >>Rechnerkennung<< der Maschine halten. Diese Datenstrukturen konnen im Allgemeinen nicht atomar verandert werden. Da erwartet wird, dass sich die >>Rechnerkennung<< im Allgemeinen nicht andert, wird die daraus lesende Funktionen (gethostid(3)) als sicher betrachtet, wahrend die verandernde 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 nebenlaufigen Veranderungen sicherzustellen. Diese Funktionen sind allerdings nicht als MT-Unsicher markiert, da Funktionen, die diese Datenstruktur verandern, alle mit const:sigintr markiert sind und als unsicher betrachtet werden. Da sie unsicher sind, durfen letztere nicht aufgerufen werden, wenn mehrere Threads laufen oder asynchrone Signale aktiviert sind, und daher die Datenstruktur tatsachlich in diesen Kontexten als konstant betrachtet werden kann, wodurch erstere sicher sind. cwd Mit cwd als MT-Sicherheitsproblem kommentierte Funktionen konnen temporar wahrend ihrer Ausfuhrung ihr aktuelles Arbeitsverzeichnis andern, wodurch relative Pfadnamen in anderen Threads oder innerhalb asynchroner Signal- oder Abbruch-Handhaber auf unvorhergesehene Weise aufgelost werden konnten. 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) konnte das Vermeiden dieser Option eine gute Alternative zur Verwendung vollstandiger Pfadnamen oder Systemaufrufen mit relativen Dateideskriptoren (z.B. openat(2)) sein. :Kennzeichner Funktionen konnen 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 Fallen 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 haufigste Verwendung von Kennzeichnern ist die Bereitstellung logischer Gruppen von Funktionen und Argumenten, die durch die gleichen Synchronisationsprimitiven geschutzt werden mussen, um eine sichere Aktion in einem gegebenen Kontext sicherzustellen. /Bedingung Einige Sicherheitsanmerkungen konnen von Bedingungen abhangen. 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) UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . Linux man-pages 6.06 1. November 2023 Attribute(7)