Provided by: manpages-de-dev_2.16-1_all bug

BEZEICHNUNG

       capget, capset - Setzt/ermittelt die Capabilities von Thread(s)

ÜBERSICHT

       #include <sys/capability.h>

       int capget(cap_user_header_t hdrp, cap_user_data_t datap);

       int capset(cap_user_header_t hdrp, const cap_user_data_t datap);

BESCHREIBUNG

       Diese   zwei   Systemaufrufe   sind   die   rohe   Kernelschnittstelle   zum  Ermitteln  und  Setzen  der
       Thread-Capabilities. Die Systemaufrufe sind nicht nur Linux-spezifisch, auch  die  Kernel-API  wird  sich
       wahrscheinlich   ändern   und   die   Verwendung   dieser  Systemaufrufe  (insbesondere  das  Format  der
       cap_user_*_t-Typen) unterliegt  in  jeder  Kernel-Revision  Erweiterungen,  aber  alte  Programme  werden
       weiterhin funktionieren.

       Die  portablen  Schnittstellen sind cap_set_proc(3) und cap_get_proc(3); falls möglich, sollten Sie diese
       Schnittstellen in Anwendungen benutzen.

   Aktuelle Details
       Nachdem Sie gewarnt wurden, hier einige aktuelle Kernel-Datails. Die Strukturen sind wie folgt definiert:

           #define _LINUX_CAPABILITY_VERSION_1  0x19980330
           #define _LINUX_CAPABILITY_U32S_1     1

                   /* V2 hinzugefügt in Linux 2.6.25; veraltet */
           #define _LINUX_CAPABILITY_VERSION_2  0x20071026
           #define _LINUX_CAPABILITY_U32S_2     2

                   /* V3 in Linux 2.6.26 hinzugefügt */
           #define _LINUX_CAPABILITY_VERSION_3  0x20080522
           #define _LINUX_CAPABILITY_U32S_3     2

           typedef struct __user_cap_header_struct {
              __u32 version;
              int pid;
           } *cap_user_header_t;

           typedef struct __user_cap_data_struct {
              __u32 effective;
              __u32 permitted;
              __u32 inheritable;
           } *cap_user_data_t;

       Die Felder effective, permitted  und  inheritable  sind  Bitmasken  der  in  capabilities(7)  definierten
       Capabilities. Beachten Sie, dass CAP_*-Werte Bitindizes sind und bitweise verschoben werden müssen, bevor
       per  ODER  auf  die  Bitfelder zugegriffen wird. Um die Strukturen zu definieren, die an den Systemaufruf
       übergeben  werden  sollen,  müssen   Sie   die   Namen   struct   __user_cap_header_struct   und   struct
       __user_cap_data_struct verwenden, da die Typedefs nur Zeiger sind.

       Kernel vor 2.6.25 bevorzugen 32-bit-Capabilities mit Version _LINUX_CAPABILITY_VERSION_1. In Linux 2.6.25
       wurden  64-bit-Capability-Sets  hinzugefügt,  mit  Version _LINUX_CAPABILITY_VERSION_2. Allerdings gab es
       einen API-Glitch, und Linux 2.6.26 fügte _LINUX_CAPABILITY_VERSION_3 hinzu, um das Problem zu beheben.

       Beachten Sie, dass 64-Bit-Capabilities datap[0] und datap[1] verwenden, während  32-Bit-Capabilities  nur
       datap[0] verwenden.

       In  Kerneln,  die  Datei-Capabilities unterstützen (VFS-Capabilities-Unterstützung), verhalten sich diese
       Systemaufrufe etwas anders. Diese Unterstützung wurde in Linux 2.6.24 hinzugefügt  und  wurde  später  in
       Linux 2.6.33 korrigiert (nicht-optional).

       Für  capget()-Aufrufe  können die Capabilities eines Prozesses über die Angabe der Prozesskennung mit dem
       Feldwert hdrp->pid ermittelt werden.

       Für Details der Daten siehe capabilities(7).

   Mit VFS-Capabilities-Unterstützung
       VFS-Capabilities setzen  ein  erweitertes  Dateiattribut  ein  (siehe  xattr(7)),  um  das  Anhängen  von
       Capabilities  an  Dateien  zu  erlauben. Dieses Privilegienmodell ersetzt die Kernel-Unterstützung dafür,
       dass ein Prozess asynchron die  Capabilities  eines  anderen  setzt.  Das  heißt,  das  auf  Kerneln  mit
       VFS-Capability-Unterstützung  beim  Aufruf  von  capset() der einzige für hdrp->pid erlaubte Wert 0, oder
       äquivalent der von gettid(2) zurückgelieferte Wert, ist.

   Ohne VFS-Capabilities-Unterstützung
       Auf älteren Kerneln, die keine Unterstützung  für  VFS-Capabilities  bieten,  kann  capset(),  falls  der
       Aufrufende über die Capability CAP_SETPCAP verfügt, nicht nur zum Ändern der Capabilities des Aufrufenden
       sondern  auch der Capabilities anderer Threads verwandt werden. Dieser Aufruf greift auf die Capabilities
       des durch das pid-Feld von hdrp beschriebenen Threads zu, wenn das Feld von Null  verschieden  ist;  wenn
       pid gleich 0 ist, wird auf die Capabilities des aufrufenden Threads zugegriffen. Falls sich pid auf einen
       single-threaded  Prozess  bezieht,  kann  pid  auch als herkömmliche Prozesskennung angegeben werden. Der
       Zugriff auf einen Thread eines Multithread-Prozesses erfordert eine Thread-Kennung vom Typ, den gettid(2)
       zurückgibt. Für capset() kann pid auch -1 sein, d.h.  die  Änderung  wird  für  alle  Threads  außer  dem
       Aufrufenden  und  init(1)  durchgeführt; ein Wert kleiner als -1 bewirkt die Änderung für alle Mitglieder
       der Prozessgruppe, deren ID -pid ist.

RÜCKGABEWERT

       Bei Erfolg wird Null zurückgegeben. Bei  einem  Fehler  wird  -1  zurückgegeben  und  errno  entsprechend
       gesetzt.

       Die  Aufrufe  schlagen  mit  dem Fehler EINVAL fehl und das Feld version von hdrp wird auf den vom Kernel
       bevorzugten Wert von _LINUX_CAPABILITY_VERSION_?  gesetzt,  wenn  ein  nicht  unterstützter  version-Wert
       angegeben   wird.   Auf   diese   Weise   kann   herausgefunden   werden,   wie  die  derzeit  bevorzugte
       Capability-Revision lautet.

FEHLER

       EFAULT Ungültige Speicheradresse. hdrp darf nicht NULL sein. datap darf NULL nur sein, wenn der  Benutzer
              versucht, das vom Kernel unterstützte bevorzugte Capability-Versionsformat zu ermitteln.

       EINVAL Eines der Argumente war ungültig.

       EPERM  Es wurde versucht, eine Capability zu der erlaubten Menge hinzuzufügen oder eine Capability in der
              effektiven oder vererbbaren Menge zu setzen, die nicht in der erlaubten Menge enthalten ist.

       EPERM  Der  Aufrufende  versuchte,  capset()  zu  verwenden,  um  die  Capabilities  eines von ihm selbst
              verschiedenen Threads zu verändern, hatte dazu aber nicht die benötigten Privilegien. Für  Kernel,
              die  VFS-Capabilities  unterstützen,  ist dies nie erlaubt. Für Kernel ohne VFS-Unterstützung wird
              die Capability CAP_SETPCAP benötigt. (Ein Fehler in Kerneln vor 2.6.11 führte  dazu,  dass  dieser
              Fehler  auch  auftreten  konnte,  falls  ein Thread ohne diese Capability versuchte, seine eigenen
              Capabilities zu ändern, indem er das Feld pid auf einen  von  numerisch  Null  verschiedenen  Wert
              (d.h. den von getpid(2) zurückgelieferten Wert) anstatt 0 wählte.)

       ESRCH  Kein solcher Thread.

KONFORM ZU

       Diese Systemaufrufe sind Linux-spezifisch.

ANMERKUNGEN

       Die  portable  Schnittstelle der Capability-Abfrage- und -Setzfunktionen wird durch die Bibliothek libcap
       bereitgestellt, die unter folgender Adresse erhältlich ist:
       http://git.kernel.org/cgit/linux/kernel/git/morgan/libcap.git

SIEHE AUCH

       clone(2), gettid(2), capabilities(7)

KOLOPHON

       Diese Seite ist Teil der Veröffentlichung  5.03  des  Projekts  Linux-man-pages.  Eine  Beschreibung  des
       Projekts, Informationen, wie Fehler gemeldet werden können sowie die aktuelle Version dieser Seite finden
       sich unter https://www.kernel.org/doc/man-pages/.

ÜBERSETZUNG

       Die    deutsche    Übersetzung    dieser    Handbuchseite    wurde    von    Martin    Eberhard   Schauer
       <Martin.E.Schauer@gmx.de>,  Mario  Blättermann  <mario.blaettermann@gmail.com>,  Dr.   Tobias   Quathamer
       <toddy@debian.org> und Helge Kreutzmann <debian@helgefjell.de> erstellt.

       Diese  Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 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
       <debian-l10n-german@lists.debian.org>.

Linux                                             6. März 2019                                         CAPGET(2)