Provided by: manpages-de-dev_4.15.0-9_all 
BEZEICHNUNG
capget, capset - Setzt/ermittelt die Capabilities von Thread(s)
ÜBERSICHT
#include <linux/capability.h> /* Definition der Konstanten CAP_*
und _LINUX_CAPABILITY_* */
#include <sys/syscall.h> /* Definition der Konstanten SYS_* */
#include <unistd.h>
int syscall(SYS_capget, cap_user_header_t hdrp,
cap_user_data_t dataz);
int syscall(SYS_capset, cap_user_header_t hdrp,
const cap_user_data_t dataz);
Hinweis: Glibc stellt keine Wrapper für diese Systemaufrufe bereit; rufen Sie sie mittels
syscall(2) auf.
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, siehe ANMERKUNGEN.
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 dataz[0] und dataz[1] verwenden, während
32-Bit-Capabilities nur dataz[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
Kennung gleich -pid ist.
RÜCKGABEWERT
Bei Erfolg wird Null zurückgegeben. Bei einem Fehler wird -1 zurückgegeben und errno
gesetzt, um den Fehler anzuzeigen.
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. dataz 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 Es wurde versucht, eine Capability zu der vererbbaren Menge hinzuzufügen und
entweder:
* diese Capability war nicht in der Begrenzungsmenge des Aufrufenden; oder
* die Capability war nicht in der erlaubten Menge des Aufrufenden und dem
Aufrufenden fehlte die Capability CAP_SETPCAP in seiner effektiven Menge.
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.13 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 ⟨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⟩.