capget(2) System Calls Manual capget(2)
NOM
capget, capset - Configurer les capacités des threads
BIBLIOTHÈQUE
Bibliothèque C standard (libc, -lc)
SYNOPSIS
#include <linux/capability.h> /* Definition of CAP_* and
_LINUX_CAPABILITY_* constants */
#include <sys/syscall.h> /* Definition of SYS_* constants */
#include <unistd.h>
int syscall(SYS_capget, cap_user_header_t hdrp,
cap_user_data_t datap);
int syscall(SYS_capset, cap_user_header_t hdrp,
const cap_user_data_t datap);
Note : la glibc ne fournit pas de fonction autour de cet appel système,
l'utilisation de syscall(2) est requise.
DESCRIPTION
Ces deux appels système constituent l'interface brute du noyau pour
configurer ou lire les capacités d'un thread. Non seulement ces appels
système sont spécifiques à Linux, mais l'API du noyau est susceptible
de changer. L'utilisation de ces appels système (en particulier le for-
mat du type cap_user_*_t) risque d'être étendue lors de nouvelles mises
à jour du noyau, mais les anciens programmes continueront à fonction-
ner.
Les interfaces portables sont constituées des fonctions cap_set_proc(3)
et cap_get_proc(3) ; si possible, utilisez plutôt ces routines dans vos
applications ; voir les NOTES.
Détails actuels
Maintenant que vous avez été avertis, quelques détails du noyau actuel.
Les structures sont définies comme suit.
#define _LINUX_CAPABILITY_VERSION_1 0x19980330
#define _LINUX_CAPABILITY_U32S_1 1
/* V2 ajoutée à Linux 2.6.25 ; obsolète */
#define _LINUX_CAPABILITY_VERSION_2 0x20071026
#define _LINUX_CAPABILITY_U32S_2 2
/* V3 ajoutée à Linux 2.6.26 */
#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;
Les champs effective, permitted et inheritable sont des masques de bits
de capacités définies dans capabilities(7). Notez que les valeurs CAP_*
sont indices de bits et nécessitent d'être décalées avant le OU logique
avec le champ de bits. Pour définir les structures à passer à l'appel
système, vous devez utiliser les noms struct __user_cap_header_struct
et struct __user_cap_data_struct car les typedef ne sont que des poin-
teurs.
Les noyaux antérieurs à Linux 2.6.25 préfèrent les capacités 32 bits
avec la version _LINUX_CAPABILITY_VERSION_1. Linux 2.6.25 a ajouté
l'ensemble des capacités 64 bits avec la version _LINUX_CAPABILITY_VER-
SION_2. Mais il y avait un bogue dans l'API, donc Linux 2.6.26 a ajouté
_LINUX_CAPABILITY_VERSION_3 pour corriger le problème.
Notez que les capacités 64 bits utilisent datap[0] et datap[1], tandis
que celles 32 bits n'utilisent que datap[0].
Sur les noyaux qui gèrent les capacités de fichier (VFS capabilities
support), ces appels système se comportent légèrement autrement. Cette
prise en charge a été ajoutée en option à Linux 2.6.24, avant de deve-
nir incluse (non optionnelle) dans Linux 2.6.33.
Pour les appels capget(), on peut tester les capacités de n'importe
quel processus en indiquant l'identifiant du processus avec la valeur
du champ hdrp->pid.
Pour les détails sur les données, consultez capabilities(7).
Avec la prise en charge des capacités VFS
Les capacités VFS utilisent un attribut de fichier étendu (voir
xattr(7)) pour pouvoir se rattacher à des exécutables. Ce modèle de
privilèges rend obsolète la prise en charge par le noyau du paramétrage
asynchrone des capacités d'un processus par un autre. C'est-à-dire que,
avec la prise en charge VFS, pour les appels à capset() les seules va-
leurs permises pour hdrp->pid sont 0 ou, de manière équivalente, la va-
leur renvoyée par gettid(2).
Sans la gestion des capacités VFS
Sur les anciens noyaux qui ne gèrent pas les capacités VFS, capset()
peut être utilisé, si l'appelant a la capacité CAP_SETPCAP, pour modi-
fier non seulement les capacités propres à l'appelant, mais aussi les
capacités d'autres threads. L'appel s'applique aux capacités du thread
indiqué par le champ pid de hdrp lorsqu'il n'est pas nul, ou à celles
du thread courant si pid vaut 0. Si pid correspond à un processus
n'utilisant pas les threads, pid peut être un identifiant de processus
classique. Pour configurer les capacités d'un thread faisant partie
d'un processus multithread, il faut utiliser un identifiant de thread
du type que renvoie gettid(2). Pour capset(), pid peut également être
-1, ce qui affecte tous les threads sauf l'appelant et init(1), ou bien
une valeur inférieure à -1, ce qui applique la modification à tous les
membres du groupe de processus identifiés par -pid.
VALEUR RENVOYÉE
En cas de succès, zéro est renvoyé. En cas d'erreur, -1 est renvoyé et
errno est définie pour préciser l'erreur.
Les appels échoueront avec l'erreur EINVAL, et définiront le champ ver-
sion de hdrp avec la valeur _LINUX_CAPABILITY_VERSION_? préférée par le
noyau quand une version non prise en charge est fournie. De cette fa-
çon, on peut tester quelle est la révision actuelle de capacité préfé-
rée.
ERREURS
EFAULT Mauvaise adresse mémoire. hdrp ne doit pas être NULL. datap ne
peut être NULL que quand l'utilisateur cherche à déterminer la
version du format préféré des capacités gérée par le noyau.
EINVAL Un argument est non valable.
EPERM Une tentative a été opérée pour ajouter une capacité dans l'en-
semble permitted, ou pour placer une capacité dans l'ensemble
effective hors de l'ensemble permitted.
EPERM Une tentative a été faite pour ajouter une capacité dans l'en-
semble inheritable et soit :
• cette capacité n'était pas présente dans l'ensemble appli-
cable à l'appel ; soit
• cette capacité n'était pas dans l'ensemble permitted pour
l'appel et l'appelant n'avait pas de capacité CAP_SETPCAP
dans son ensemble effectif.
EPERM Le processus appelant a tenté d'utiliser capset() pour modifier
les capacités d'un thread autre que lui-même, sans avoir les
privilèges nécessaires. Pour les noyaux avec la gestion des ca-
pacités VFS, ce n'est jamais permis. Pour les noyaux sans la
gestion des capacités VFS, la capacité CAP_SETPCAP est requise.
(En raison d'un bogue dans les noyaux antérieurs à Linux 2.6.11,
cette erreur était aussi renvoyée si un thread sans cette capa-
cité tentait de modifier ses propres capacités en indiquant une
valeur non nulle de pid (la valeur renvoyée par getpid(2), au
lieu de 0).
ESRCH Pas de thread correspondant.
STANDARDS
Ces appels système sont spécifiques à Linux.
NOTES
L'interface portable pour les fonctions de lecture des capacités et de
configuration est fournie par la bibliothèque libcap disponible à :
⟨http://git.kernel.org/cgit/linux/kernel/git/morgan/libcap.git⟩
VOIR AUSSI
clone(2), gettid(2), capabilities(7)
TRADUCTION
La traduction française de cette page de manuel a été créée par Chris-
tophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin <ste-
phan.rafin@laposte.net>, Thierry Vignaud <tvignaud@mandriva.com>, Fran-
çois Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe Gué-
rard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-luc.cou-
lon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux
<thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centra-
liens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard <si-
mon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@de-
bian.org>, David Prévot <david@tilapin.org>, Cédric Boutillier <ce-
dric.boutillier@gmail.com>, Frédéric Hantrais <fhantrais@gmail.com> et
Jean-Philippe MENGUAL <jpmengual@debian.org>
Cette traduction est une documentation libre ; veuillez vous reporter à
la GNU General Public License version 3
⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ concernant les conditions
de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel,
veuillez envoyer un message à ⟨debian-l10n-french@lists.debian.org⟩.
Pages du manuel de Linux 6.03 5 février 2023 capget(2)
Generated by dwww version 1.15 on Sat Jun 29 01:33:50 CEST 2024.