Provided by: manpages-fr-dev_3.57d1p1-1_all bug

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