[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFR] man://manpages-de/setpriv.1.po (Teil 1/2)



Hallo Helge,

Am Sonntag, 10. März 2019, 08:51:59 CET schrieb Helge Kreutzmann:
> Moin,
> On Sun, Mar 10, 2019 at 12:30:38AM +0100, Mario Blättermann wrote:
> > # abgeleiteten → vererbten? Wobei mir das nicht so richtig gefällt…
> > #. type: Plain text
> > #: archlinux debian-unstable
> > msgid ""
> > "Sets or queries various Linux privilege settings that are inherited across "
> > "B<execve>(2)."
> > msgstr ""
> > "Legt die verschiedenen über B<execve>(2) abgeleiteten"
> > " Linux-Berechtigungseinstellungen fest oder fragt diese ab."
> 
> execve(2) (auch auf Deutsch) führt ein Programm aus, dass dann was
> erbt, d.h. ihm wird etwas vererbt.
> 
OK, dann schreibe ich »vererbt«. Ich habe ja nichts gegen den Begriff, aber wie
ich zu Eriks Kommentar schon schrieb, war mir hier die Richtung der
Vererbung bzw. Ererbung nicht ganz klar.

> > #. type: Plain text
> > #: archlinux debian-unstable
> > msgid ""
> > "In comparison to B<su>(1)  and B<runuser>(1), B<setpriv>(1)  neither uses "
> > "PAM, nor does it prompt for a password.  It is a simple, non-set-user-ID "
> > "wrapper around B<execve>(2), and can be used to drop privileges in the same "
> > "way as B<setuidgid>(8)  from B<daemontools>, B<chpst>(8)  from B<runit>, or "
> > "similar tools shipped by other service managers."
> > msgstr ""
> > "Im Vergleich zu B<su>(1) und B<runuser>(1) verwendet B<setpriv>(1) weder PAM,"
> > " noch bittet es um die Eingabe eines Passworts. Es ist ein einfacher, keine"
> > " Benutzerkennung setzender Aufsatz auf <execve>(2) und kann zum Setzen der"
> > " Berechtigungen auf die gleiche Weise wie bei B<setuidgid>(8) aus B<daemontools>,"
> > " B<chpst>(8) aus B<runit> oder ähnlichen Werkzeugen verwendet werden, die"
> > " Teil von anderen Diensteverwaltern sind."
> 
> Bisher haben wird durchgängig »Wrapper« im technischen Kontext so
> (unübersetzt) gelassen, siehe Wortliste. Wäre gut, wenn es hier auch
> so wäre. Schließlich ist »drop« nicht setzen. Insgesamt würde ich den 
> zweiten Satz wie folgt schreiben:
> Es ist ein einfacher Wrapper für B<execve>(2), der keine
> Benutzerkennung setzt und zum Abgeben von Privilegien auf die gleiche
> Art wie B<setuidgid>(8) aus B<daemontools>, B<chpst>(8) aus
> B<runit> oder ähnlichen Werkzeugen, die von anderen Diensteverwaltern
> ausgeliefert werden, verwandt werden.
> 
Habe ich fast so übernommen, es fehlte nur noch ein »kann« am Ende.

> > #. type: Plain text
> > #: archlinux debian-unstable
> > msgid ""
> > "Set supplementary groups.  The argument is a comma-separated list of GIDs or "
> > "names."
> > msgstr ""
> > "legt zusätzliche Gruppen fest. Das Argument ist eine durch Kommata getrennte"
> > " Liste von Gruppenkennungen oder Namen."
> 
> s/legt … fest/setzt …/
> 
OK.

> > #. type: TP
> > #: archlinux debian-unstable
> > #, no-wrap
> > msgid ""
> > "B<--inh-caps> (B<+>|B<->)I<cap>...  or  B<--ambient-caps> (B<+>|B<->)I<cap"
> > ">...  or  B<--bounding-set> (B<+>|B<->)I<cap>..."
> > msgstr ""
> > "B<--inh-caps> (B<+>|B<->)I<Capability> … oder B<--ambient-caps> (B<+>|B<->)I<"
> > "Capability> … oder  B<--bounding-set> (B<+>|B<->)I<Capability> …"
> 
> In dem nachfolgenden Absatz verwendest Du die Namen der Argumente
> (und erläuterst sie auch). Daher würde ich hier klar dafür plädieren,
> in beiden Fällen:
> s/I<Capability>/I<Cap>/
> 
OK.

> Alternativ müsstest Du im nächsten Absatz die Argumente ausschreiben,
> aber dann werden die Sätze noch schwerer lesbar, da die Argumente
> weniger gut als solche erkennbar wären.
> 
OK, aber ich muss dann cap → Cap. 

> > #. type: Plain text
> > #: archlinux debian-unstable
> > msgid ""
> > "Set the inheritable capabilities, ambient capabilities or the capability "
> > "bounding set.  See B<capabilities>(7).  The argument is a comma-separated "
> > "list of B<+>I<cap> and B<->I<cap> entries, which add or remove an entry "
> > "respectively. I<cap> can either be a human-readable name as seen in "
> > "B<capabilities>(7)  without the I<cap_> prefix or of the format B<cap_N>I<,> "
> > "where I<N> is the internal capability index used by Linux.  B<+all> and B<-"
> > "all> can be used to add or remove all caps.  The set of capabilities starts "
> > "out as the current inheritable set for B<--inh-caps>, the current ambient "
> > "set for B<--ambient-caps> and the current bounding set for B<--bounding-"
> > "set>.  If you drop something from the bounding set without also dropping it "
> > "from the inheritable set, you are likely to become confused.  Do not do that."
> > msgstr ""
> > "setzt die vererbbaren Capabilities, Ambient-Capabilities oder den "
> > "Capabilities-Begrenzungssatz. Siehe B<capabilities>(7). Das Argument ist eine "
> > "durch Kommata getrennte Liste von B<+>I<cap>- beziehungsweise B<->I<cap>-"
> > "Einträgen, die jeweils einen entsprechenden Eintrag hinzufügen. I<Capability> "
> > "kann entweder ein menschenlesbarer Name wie in B<capabilities>(7) sein (ohne "
> > "das Präfix I<cap_>) oder als B<cap_N> formatiert sein, wobei I<N> der von "
> > "Linux intern verwendete Capability-Index ist. B<+all> und B<-all> können Sie "
> > "zum Hinzufügen oder Entfernen aller Capabilities verwenden. Der Capabilities-"
> > "Satz beginnt als der aktuell vererbbare Satz für B<--inh-caps>, der aktuelle "
> > "Ambient-Satz für B<--ambient-caps> und der aktuelle Begrenzungssatz für "
> > "B<--bounding-set>. Wenn Sie etwas aus dem Begrenzungssatz weglassen, ohne es "
> > "zugleich aus dem vererbbaren Satz wegzulassen, wird Sie das wahrscheinlich "
> > "verwirren. Sie sollten das nicht tun."
> 
> Hier bitte in die Übersetzung von capabilities(7) schauen, da habe ich
> viel Arbeit reingesteckt. (Gilt bei diesen technischen Handbuchseiten
> generell, bitte erstmal grep(1)en, was wir schon haben).
> 
> s/Ambient-Capabilities/Umgebungs-Capabilities/
> s/den Capabilities-Begrenzungssatz/die Capabilitiy-Begrenzungsmenge/
> 
> s/Eintrag hinzufügen./Eintrag hinzufügen oder entferen./
> 
> Für die Argumentnamen verwendest Du teilweise die Kurzform I<cap>,
> teilweise die Langform I<Capability>, das sollte durchgehend
> einheitlich sein, siehe meine Anmerkung zur vorherigen Zeichenkette.
> 
> s/Der Capabilities-Satz beginnt als der/
>   Die Gruppe der Capabalities ist anfänglich der/
> 
> s/der aktuelle Ambient-Satz/
>   die aktuelle Umgebungsgruppe/
> 
> s/der aktuelle Begrenzungssatz/die aktuelle Begrenzungsmenge/
> 
> s/dem Begrenzungssatz/der Begrenzungsmenge/
> s/dem vererbbaren Satz/der vererbaren Gruppe/
> 
> > #. type: Plain text
> > #: archlinux debian-unstable
> > msgid ""
> > "Set the I<no_new_privs> bit.  With this bit set, B<execve>(2)  will not "
> > "grant new privileges.  For example, the set-user-ID and set-group-ID bits as "
> > "well as file capabilities will be disabled.  (Executing binaries with these "
> > "bits set will still work, but they will not gain privileges.  Certain LSMs, "
> > "especially AppArmor, may result in failures to execute certain programs.)  "
> > "This bit is inherited by child processes and cannot be unset.  See "
> > "B<prctl>(2)  and I<Documentation/\\:prctl/\\:no_\\:new_\\:privs.txt> in the "
> > "Linux kernel source."
> > msgstr ""
> > "setzt das I<no_new_privs>-Bit. Wenn dieses gesetzt ist, gewährt B<execve>(2)"
> > " keine neuen Privilegien. Zum Beispiel werden sowohl die Bits »set-user-ID«"
> > " und »set-group-ID« als auch die Datei-Capabilities deaktiviert. Die"
> > " Ausführung von Programmen wird mit diesen gesetzten Bits noch möglich sein,"
> > " aber sie werden keine Berechtigungen erlangen können. Bestimmte Linux "
> > " Security Modules (LSMs), vor allem AppArmor, könnten das Ausführen bestimmter"
> > " Programme verhindern. Dieses Bit wird an Kindprozesse vererbt"
> > " und kann nicht zurückgesetzt werden. Siehe B<prctl>(2) und I<"
> > "Documentation/\\:prctl/\\:no_\\:new_\\:privs.txt> in den Linux-Kernelquellen."
> 
> Verwendest Du »Privilegien« und »Berechtigungen« synonym? Ich würde
> vorschlagen, eine der beiden Begriffe durchgehend zu verwenden, um
> keine technischen Fragen beim deutschen Leser aufzuwerfen. (Ich habe
> jetzt nicht in unserem Kanon geschaut, was (häufiger) verwandt wird).
> 
Ich habe hier in dieser Datei erst einmal konsistent »Privilegien« verwendet.

Gruß Mario



Reply to: