Provided by: manpages-fr-dev_3.17.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 p_entte, cap_user_data_t p_donnes);

       int capset(cap_user_header_t p_entte, const cap_user_data_t donnes);


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 de varier lors de nouvelles mises à jour du
       noyau.

       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;

       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.  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 qu’avec la prise en charge
       VFS, 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
       p_entte  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.


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