[RFR] man://manpages-de/po/man2/setfsuid.2.po

[Chris Leick <c.leick@vollbio.de>]

Hallo,

in der Handbuchseite von setfsuid.2 sind zwei neue Zeichenketten. Bitte 
um Korrektur.

Gruß,
Chris

#. type: Plain text
# FIXME s/privilged/privileged/
msgid ""
"At the time when this system call was introduced, one process could send a "
"signal to another process with the same effective user ID.  This meant that "
"if a privilged process changed its effective user ID for the purpose of file "
"permission checking, then it could become vulnerable to receiving signals "
"sent by another (unprivileged) process with the same user ID.  The "
"filesystem user ID attribute was thus added to allow a process to change its "
"user ID for the purposes of file permission checking without at the same "
"time becoming vulnerable to receiving unwanted signals.  Since Linux 2.0, "
"signal permission handling is different (see B<kill>(2)), with the result "
"that a process change can change its effective user ID without being "
"vulnerable to receiving signals from unwanted processes.  Thus, B<setfsuid>"
"()  is nowadays unneeded and should be avoided in new applications (likewise "
"for B<setfsgid>(2))."
msgstr ""
"Zum Zeitpunkt, an dem dieser Systemaufruf erfolgte, konnte ein Prozess ein "
"Signal an einen anderen Prozess mit der selben effektiven Benutzer-ID senden. "
"Dies bedeutete, dass ein privilegierter Prozess, falls er zum Prüfen von "
"Dateizugriffsrechten seine effektive Benutzer-ID änderte, verwundbar wurde, "
"Signale von einem anderen (nicht privilegierten) Prozess mit der selben ID zu "
"empfangen. Daher wurde das Benutzer-ID-Attribut des Dateisystems hinzugefügt, "
"um einem Prozess das �ndern seiner Benutzer-ID zum Prüfen der "
"Dateizugriffsrechte zu ermöglichen, ohne gleichzeitig verwundbar für den "
"Empfang unerwünschter Signale zu werden. Seit Linux 2.0 ist der Umgang mit "
"Signalrechten anders gelöst (siehe B<kill>(2)) was dazu führt, dass ein "
"Prozess seine effektive Benutzer-ID ändern kann, ohne empfänglich für Signale "
"von unerwünschten Prozessen zu werden. Daher wird B<setfsuid>() heutzutage "
"nicht mehr benötigt und sollte in neuen Anwendungen vermieden werden (ebenso "
"B<setfsgid>(2))."

#. type: Plain text
msgid ""
"No error indications of any kind are returned to the caller, and the fact "
"that both successful and unsuccessful calls return the same value makes it "
"impossible to directly determine whether the call succeeded or failed.  "
"Instead, the caller must resort to looking at the return value from a "
"further call such as I<setfsuid(-1)> (which will always fail), in order to "
"determine if a preceding call to B<setfsuid>()  changed the filesystem user "
"ID.  At the very least, B<EPERM> should be returned when the call fails "
"(because the caller lacks the B<CAP_SETUID> capability)."
msgstr ""
"Es werden keine Anhaltspunkte für Fehler an den Aufrufenden zurückgegeben und "
"die Tatsache, dass sowohl erfolgreiche als auch nicht erfolgreiche Aufrufe "
"den selben Wert zurückgeben, macht es unmöglich, direkt zu bestimmen, ob der "
"Aufruf erfolgreich war oder fehlschlug. Stattdessen musste der Aufrufende auf "
"die Betrachtung des Rückgabewerts eines weiteren Prozesses wie "
"I<setfsuid(-1)> zurückgreifen (der immer fehlschlägt), um zu bestimmen, ob "
"ein vorheriger Aufruf von B<setfsuid>() die Dateisystembenutzer-ID geändert "
"hat. Zumindest sollte B<EPERM> zurückgegeben werden, wenn der Aufruf "
"fehlschlägt (da dem Aufrufenden die B<CAP_SETUID>-Fähigkeit fehlt)."