capget(2) System Calls Manual capget(2) NOM capget, capset - Configurer les capacites des threads BIBLIOTHEQUE Bibliotheque C standard (libc, -lc) SYNOPSIS #include /* Definition of CAP_* and _LINUX_CAPABILITY_* constants */ #include /* Definition of SYS_* constants */ #include 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 systeme, l'utilisation de syscall(2) est requise. DESCRIPTION Ces deux appels systeme constituent l'interface brute du noyau pour configurer ou lire les capacites d'un thread. Non seulement ces appels systeme sont specifiques a Linux, mais l'API du noyau est susceptible de changer. L'utilisation de ces appels systeme (en particulier le format du type cap_user_*_t) risque d'etre etendue lors de nouvelles mises a jour du noyau, mais les anciens programmes continueront a fonctionner. Les interfaces portables sont constituees des fonctions cap_set_proc(3) et cap_get_proc(3) ; si possible, utilisez plutot ces routines dans vos applications ; voir les NOTES. Details actuels Maintenant que vous avez ete avertis, quelques details du noyau actuel. Les structures sont definies comme suit. #define _LINUX_CAPABILITY_VERSION_1 0x19980330 #define _LINUX_CAPABILITY_U32S_1 1 /* V2 ajoutee a Linux 2.6.25 ; obsolete */ #define _LINUX_CAPABILITY_VERSION_2 0x20071026 #define _LINUX_CAPABILITY_U32S_2 2 /* V3 ajoutee a 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 capacites definies dans capabilities(7). Notez que les valeurs CAP_* sont indices de bits et necessitent d'etre decalees avant le OU logique avec le champ de bits. Pour definir les structures a passer a l'appel systeme, vous devez utiliser les noms struct __user_cap_header_struct et struct __user_cap_data_struct car les typedef ne sont que des pointeurs. Les noyaux anterieurs a Linux 2.6.25 preferent les capacites 32 bits avec la version _LINUX_CAPABILITY_VERSION_1. Linux 2.6.25 a ajoute l'ensemble des capacites 64 bits avec la version _LINUX_CAPABILITY_VERSION_2. Mais il y avait un bogue dans l'API, donc Linux 2.6.26 a ajoute _LINUX_CAPABILITY_VERSION_3 pour corriger le probleme. Notez que les capacites 64 bits utilisent datap[0] et datap[1], tandis que celles 32 bits n'utilisent que datap[0]. Sur les noyaux qui gerent les capacites de fichier (VFS capabilities support), ces appels systeme se comportent legerement autrement. Cette prise en charge a ete ajoutee en option a Linux 2.6.24, avant de devenir incluse (non optionnelle) dans Linux 2.6.33. Pour les appels capget(), on peut tester les capacites de n'importe quel processus en indiquant l'identifiant du processus avec la valeur du champ hdrp->pid. Pour les details sur les donnees, consultez capabilities(7). Avec la prise en charge des capacites VFS Les capacites VFS utilisent un attribut de fichier etendu (voir xattr(7)) pour pouvoir se rattacher a des executables. Ce modele de privileges rend obsolete la prise en charge par le noyau du parametrage asynchrone des capacites d'un processus par un autre. C'est-a-dire que, avec la prise en charge VFS, pour les appels a capset() les seules valeurs permises pour hdrp->pid sont 0 ou, de maniere equivalente, la valeur renvoyee par gettid(2). Sans la gestion des capacites VFS Sur les anciens noyaux qui ne gerent pas les capacites VFS, capset() peut etre utilise, si l'appelant a la capacite CAP_SETPCAP, pour modifier non seulement les capacites propres a l'appelant, mais aussi les capacites d'autres threads. L'appel s'applique aux capacites du thread indique par le champ pid de hdrp lorsqu'il n'est pas nul, ou a celles du thread courant si pid vaut 0. Si pid correspond a un processus n'utilisant pas les threads, pid peut etre un identifiant de processus classique. Pour configurer les capacites 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 egalement etre -1, ce qui affecte tous les threads sauf l'appelant et init(1), ou bien une valeur inferieure a -1, ce qui applique la modification a tous les membres du groupe de processus identifies par -pid. VALEUR RENVOYEE En cas de succes, zero est renvoye. En cas d'erreur, -1 est renvoye et errno est definie pour preciser l'erreur. Les appels echoueront avec l'erreur EINVAL, et definiront le champ version de hdrp avec la valeur _LINUX_CAPABILITY_VERSION_? preferee par le noyau quand une version non prise en charge est fournie. De cette facon, on peut tester quelle est la revision actuelle de capacite preferee. ERREURS EFAULT Mauvaise adresse memoire. hdrp ne doit pas etre NULL. datap ne peut etre NULL que quand l'utilisateur cherche a determiner la version du format prefere des capacites geree par le noyau. EINVAL Un argument est non valable. EPERM Une tentative a ete operee pour ajouter une capacite dans l'ensemble permitted, ou pour placer une capacite dans l'ensemble effective hors de l'ensemble permitted. EPERM Une tentative a ete faite pour ajouter une capacite dans l'ensemble inheritable et soit : - cette capacite n'etait pas presente dans l'ensemble applicable a l'appel ; soit - cette capacite n'etait pas dans l'ensemble permitted pour l'appel et l'appelant n'avait pas de capacite CAP_SETPCAP dans son ensemble effectif. EPERM Le processus appelant a tente d'utiliser capset() pour modifier les capacites d'un thread autre que lui-meme, sans avoir les privileges necessaires. Pour les noyaux avec la gestion des capacites VFS, ce n'est jamais permis. Pour les noyaux sans la gestion des capacites VFS, la capacite CAP_SETPCAP est requise. (En raison d'un bogue dans les noyaux anterieurs a Linux 2.6.11, cette erreur etait aussi renvoyee si un thread sans cette capacite tentait de modifier ses propres capacites en indiquant une valeur non nulle de pid (la valeur renvoyee par getpid(2), au lieu de 0). ESRCH Pas de thread correspondant. STANDARDS Linux. NOTES L'interface portable pour les fonctions de lecture des capacites et de configuration est fournie par la bibliotheque libcap disponible a : VOIR AUSSI clone(2), gettid(2), capabilities(7) TRADUCTION La traduction francaise de cette page de manuel a ete creee par Christophe Blaess , Stephan Rafin , Thierry Vignaud , Francois Micaux, Alain Portal , Jean-Philippe Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas Francois , Florentin Duneau , Simon Paillard , Denis Barbier , David Prevot , Cedric Boutillier , Frederic Hantrais et Jean-Philippe MENGUAL Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . Pages du manuel de Linux 6.06 31 octobre 2023 capget(2)