Provided by: manpages-fr-dev_3.65d1p1-1_all 
NOM
capget, capset - Configurer les capacités des threads
SYNOPSIS
#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);
DESCRIPTION
Depuis Linux 2.2, la toute puissance du superutilisateur (root) a été scindée en plusieurs
ensembles distincts. Chaque thread dispose d'un ensemble de capacités effectives
permettant d'identifier ses droits de réaliser certaines actions. Chaque thread a aussi un
ensemble de capacités héritables, qu'il peut transmettre au travers d'un execve(2) et un
ensemble de capacités éventuelles qu'il peut rendre effectives ou héritables.
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 format du type cap_user_*_t) risque d'être étendue lors de nouvelles mises
à jour du noyau, mais les anciens programmes continueront à fonctionner.
L'interface portable est constituée des fonctions cap_set_proc(3) et cap_get_proc(3) ; si
possible, utilisez plutôt ces routines dans vos applications. Si vous désirez vraiment
utiliser les extensions Linux, essayez d'employer plutôt les interfaces plus simples
capsetp(3) et capgetp(3).
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
#define _LINUX_CAPABILITY_VERSION_2 0x20071026
#define _LINUX_CAPABILITY_U32S_2 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;
effective, permitted et inheritable sont des champs de bits de capacité définis dans
capabilities(7). Notez que les valeurs CAP_* sont indexées par bit et nécessitent d'être
décalées avant le OU logique avec le champ de bit. 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 typedefs ne sont que des pointeurs.
Les noyau antérieurs à 2.6.25 préfèrent les capacités 32 bits avec la version
_LINUX_CAPABILITY_VERSION_1, et les noyaux 2.6.25 et suivants préfèrent les capacités
64 bits avec la version _LINUX_CAPABILITY_VERSION_2. Notez que les capacités 64 bits
utilisent datap[0] et datap[1], tandis que les capacités 32 bits n'utilisent que datap[0].
Une autre modification impactant le comportement de ces appels système est la gestion par
le noyau de fichiers de capacités (la gestion VFS des capacité). Cette gestion est
actuellement une option de compilation (ajoutée dans le noyau 2.6.24).
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.
Avec la prise en charge VFS des capacités
Avec la prise en charge VFS pour les capacités, il existe une méthode permettant d'ajouter
des capacités à des exécutables privilégiés à partir d'attributs de fichier. 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 valeurs permises pour hdrp->pid sont 0 et getpid(2), qui
sont équivalentes.
Sans la gestion VFS des capacités
Quand le noyau ne gère pas les capacités en VFS, les appels capset() peuvent s'appliquer
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(8), ou bien une valeur
inférieure à -1, ce qui applique la modification à tous les membres de groupe de processus
identifié par -pid.
Pour les détails sur les données, consultez capabilities(7).
VALEUR RENVOYÉE
S'il réussit, cet appel système renvoie 0. S'il échoue, il renvoie -1 et remplit errno en
conséquence.
Les appels échoueront avec l'erreur EINVAL, et définiront le champ version 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 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 invalide.
EPERM On a essayé d'ajouter une capacité dans l'ensemble éventuel, ou de placer une
capacité dans l'ensemble effectif ou héritable qui ne se trouvait pas dans
l'ensemble éventuel.
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 VFS des capacités, ce n'est jamais permis. Pour les noyaux sans la
gestion VFS des capacités, la capacité CAP_SETPCAP est requise. (En raison d'un
bogue dans les noyaux antérieurs à 2.6.11, cette erreur était aussi renvoyée si un
thread sans cette capacité tentait de modifier ses propres capacités en indiquant
une valeur non nulle de pid (la valeur renvoyée par getpid(2)).)
ESRCH Pas de thread correspondant.
CONFORMITÉ
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)
COLOPHON
Cette page fait partie de la publication 3.65 du projet man-pages Linux. Une description
du projet et des instructions pour signaler des anomalies peuvent être trouvées à
l'adresse http://www.kernel.org/doc/man-pages/.
TRADUCTION
Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a
<http://po4a.alioth.debian.org/> par l'équipe de traduction francophone au sein du projet
perkamon <http://perkamon.alioth.debian.org/>.
Christophe Blaess <http://www.blaess.fr/christophe/> (1996-2003), Alain Portal
<http://manpagesfr.free.fr/> (2003-2006). Julien Cristau et l'équipe francophone de
traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en écrivant à
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le paquet
manpages-fr.
Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la
commande « man -L C <section> <page_de_man> ».