NOM
capget, capset - Configurer les capacités des threads
SYNOPSIS
#undef _POSIX_SOURCE
#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);
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 fonctions 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 fonctions (en particulier le format du
type cap_user_*_t) risque d’être étendue lors de nouvelles mises à jour
du noyau, mas 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, inheritable sont des champs de bits de capacité
définis dans capability(7). Notez que les valeurs CAP_* sont indexées
par bit et nécessite 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 utilisez 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 noyau 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, voir capabilities(7).
VALEUR RENVOYÉE
En cas de réussite, zéro est renvoyé, sinon -1 est renvoyé et errno
contient le code d’erreur.
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 noyau 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://www.kernel.org/pub/linux/libs/security/linux-privs
VOIR AUSSI
clone(2), gettid(2), capabilities(7)
COLOPHON
Cette page fait partie de la publication 3.23 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
Cette page de manuel a été traduite et mise à jour par Christophe
Blaess <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis par
Alain Portal <aportal AT univ-montp2 DOT fr> jusqu’en 2006, et mise à
disposition sur http://manpagesfr.free.fr/.
Les mises à jour et corrections de la version présente dans Debian sont
directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
francophone de traduction de Debian.
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> ».