Provided by: manpages-fr-dev_3.27fr1.4-1_all bug

NOM

       capget, capset - Configurer les capacites 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 ete
       scindee en plusieurs ensembles distincts. Chaque  thread  dispose  d'un
       ensemble  de capacites effectives permettant d'identifier ses droits de
       realiser certaines actions.  Chaque  thread  a  aussi  un  ensemble  de
       capacites  heritables, qu'il peut transmettre au travers d'un execve(2)
       et un ensemble de capacites eventuelles qu'il peut rendre effectives ou
       heritables.

       Ces   deux  fonctions  constituent  l'interface  brute  du  noyau  pour
       configurer ou lire les capacites d'un thread. Non seulement ces  appels
       systeme  sont  specifiques a 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'etre etendue lors de nouvelles mises a jour
       du noyau, mais les anciens programmes continueront a fonctionner.

       L'interface portable est constituee des  fonctions  cap_set_proc(3)  et
       cap_get_proc(3) ;  si  possible,  utilisez plutot ces routines dans vos
       applications. Si vous desirez vraiment utiliser les  extensions  Linux,
       essayez  d'employer  plutot  les  interfaces plus simples capsetp(3) et
       capgetp(3).

   D'etails actuels
       Maintenant que vous avez ete avertis, quelques details du noyau actuel.
       Les structures sont definies 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 capacite
       definis dans capability(7). Notez que les valeurs CAP_*  sont  indexees
       par  bit et necessite d'etre decalees avant le OU logique avec le champ
       de bit. Pour definir les structures a passer a  l'appel  systeme,  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 anterieurs a 2.6.25 preferent les capacites 32 bits  avec  la
       version  _LINUX_CAPABILITY_VERSION_1,  et les noyaux 2.6.25 et suivants
       preferent     les     capacites     64 bits     avec     la     version
       _LINUX_CAPABILITY_VERSION_2.  Notez que les capacites 64 bits utilisent
       datap[0] et datap[1], tandis que les capacites 32 bits n'utilisent  que
       datap[0].

       Une  autre modification impactant le comportement de ces appels systeme
       est la gestion par le noyau de fichiers de capacites  (la  gestion  VFS
       des capacite). Cette gestion est actuellement une option de compilation
       (ajoutee dans le noyau 2.6.24).

       Pour les appels capget(), on peut tester  les  capacites  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'es
       Avec la prise en charge VFS pour les capacites, il existe  une  methode
       permettant  d'ajouter  des  capacites  a  des executables privilegies a
       partir d'attributs de fichier. Ce modele de privileges rend obsolete la
       prise  en  charge  par le noyau du parametrage asynchrone des capacites
       d'un processus par un autre. C'est-a-dire que, avec la prise en  charge
       VFS,  pour  les  appels  a  capset()  les  seules valeurs permises pour
       hdrp->pid sont 0 et getpid(2), qui sont equivalentes.

   Sans la gestion VFS des capacit'es
       Quand le noyau ne gere pas les capacites en VFS,  les  appels  capset()
       peuvent s'appliquer aux capacites du thread indique par le champ pid de
       hdrp lorsqu'il n'est pas nul, ou a celles du thread courant si pid vaut
       0.  Si  pid  correspond a un processus n'utilisant pas les threads, pid
       peut etre un identifiant de processus classique.  Pour  configurer  les
       capacites  d'un  thread  faisant partie d'un processus multithreade, il
       faut utiliser un identifiant de thread du type que  renvoie  gettid(2).
       Pour  capset(),  pid  peut  egalement  etre -1, ce qui affecte tous les
       threads sauf l'appelant et init(8), ou bien une valeur inferieure a -1,
       ce  qui  applique  la  modification  a  tous  les  membres de groupe de
       processus identifie par -pid.

       Pour les details sur les donnees, consultez capabilities(7).

VALEUR RENVOY'EE

       S'il reussit, cet appel systeme renvoie 0. S'il echoue, il  renvoie  -1
       et remplit errno en consequence.

       Les  appels  echoueront  avec  l'erreur  EINVAL, et definiront le champ
       version de hdrp avec la valeur _LINUX_CAPABILITY_VERSION_? preferee par
       le  noyau  quand  une version non prise en charge est fournie. De cette
       facon, on peut tester quelle est la revision de capacite preferee.

ERREURS

       EFAULT Mauvaise adresse memoire. hdrp ne doit pas etre NULL.  datap  ne
              peut  etre  NULL que quand l'utilisateur cherche a determiner la
              version du format prefere des capacites geree par le noyau.

       EINVAL Un argument est invalide.

       EPERM  On a essaye d'ajouter une capacite dans l'ensemble eventuel,  ou
              de placer une capacite dans l'ensemble effectif ou heritable qui
              ne se trouvait pas dans l'ensemble eventuel.

       EPERM  Le processus appelant a tente d'utiliser capset() pour  modifier
              les  capacites  d'un  thread  autre que lui-meme, sans avoir les
              privileges necessaires. Pour les noyaux avec la gestion VFS  des
              capacites,  ce  n'est  jamais  permis.  Pour  les noyaux sans la
              gestion VFS des capacites, la capacite CAP_SETPCAP est  requise.
              (En raison d'un bogue dans les noyaux anterieurs a 2.6.11, cette
              erreur etait aussi renvoyee si un  thread  sans  cette  capacite
              tentait  de  modifier  ses  propres  capacites  en indiquant une
              valeur non nulle de pid (la valeur renvoyee par getpid(2)).)

       ESRCH  Pas de thread correspondant.

CONFORMIT'E

       Ces appels systeme sont specifiques a Linux.

NOTES

       L'interface portable pour les fonctions de lecture des capacites et  de
       configuration est fournie par la bibliotheque libcap disponible a :
       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.27 du projet man-pages
       Linux. Une description du projet et des instructions pour signaler  des
       anomalies       peuvent       etre       trouvees      a      l'adresse
       <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

       Depuis 2010, cette traduction est maintenue a l'aide  de  l'outil  po4a
       <URL:http://po4a.alioth.debian.org/>   par   l'equipe   de   traduction
       francophone       au       sein        du        projet        perkamon
       <URL:http://perkamon.alioth.debian.org/>.

       Christophe  Blaess  <URL:http://www.blaess.fr/christophe/> (1996-2003),
       Alain  Portal  <URL:http://manpagesfr.free.fr/>  (2003-2006).    Julien
       Cristau et l'equipe francophone de traduction de Debian (2006-2009).

       Veuillez   signaler   toute   erreur   de   traduction  en  ecrivant  a
       <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
       paquet manpages-fr.

       Vous  pouvez  toujours avoir acces a la version anglaise de ce document
       en utilisant la commande << man -L C <section> <page_de_man> >>.