Provided by: manpages-fr-dev_3.23.1-1_all bug

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);

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  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> ».