capset

CAPGET(2)                  Manuel du programmeur Linux                 CAPGET(2)



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

       Les interfaces portables sont constituées des fonctions cap_set_proc(3)
       et cap_get_proc(3) ; si possible, utilisez plutôt ces routines dans vos
       applications.

   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

                  /* V2 ajoutée à Linux 2.6.25 ; obsolète */
           #define _LINUX_CAPABILITY_VERSION_2  0x20071026
           #define _LINUX_CAPABILITY_U32S_2     2

                  /* V3 ajoutée à Linux 2.6.26 */
           #define _LINUX_CAPABILITY_VERSION_3  0x20080522
           #define _LINUX_CAPABILITY_U32S_3     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 champs effective, permitted et inheritable sont des masques de bits
       de capacités définies dans capabilities(7). Notez que les valeurs CAP_*
       sont indices de bits et nécessitent d'être décalées avant le OU logique
       avec le champ de bits. 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 typedef ne sont que des pointeurs.

       Les noyaux antérieurs à 2.6.25 préfèrent les capacités 32 bits avec la
       version _LINUX_CAPABILITY_VERSION_1. Linux 2.6.25 a ajouté l'ensemble des
       capacités 64 bits avec la version _LINUX_CAPABILITY_VERSION_2. Mais il y
       avait un bogue dans l'API, donc Linux 2.6.26 a ajouté
       _LINUX_CAPABILITY_VERSION_3 pour corriger le problème.

       Notez que les capacités 64 bits utilisent datap[0] et datap[1], tandis
       que celles 32 bits n'utilisent que datap[0].

       Sur les noyaux qui gèrent les capacités de fichier (VFS capabilities
       support), ces appels système se comportent légèrement autrement. Cette
       prise en charge a été ajoutée en option à Linux 2.6.24, avant de devenir
       incluse (non optionnelle) dans Linux 2.6.33.

       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.

       Pour les détails sur les données, consultez capabilities(7).

   Avec la prise en charge des capacités VFS
       Les capacités VFS utilisent un attribut de fichier étendu (voir xattr(7))
       pour pouvoir se rattacher à des exécutables. 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 ou, de manière équivalente, la valeur renvoyée par
       getpid(2) .

   Sans la gestion des capacités VFS
       Sur les anciens noyaux qui ne gèrent pas les capacités VFS, capset() peut
       être utilisé, si l'appelant a la capacité CAP_SETPCAP, pour modifier non
       seulement les capacités propres à l'appelant, mais aussi les capacités
       d'autres threads. L'appel s'applique 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(1), ou bien une valeur
       inférieure à -1, ce qui applique la modification à tous les membres du
       groupe de processus identifiés par -pid.

VALEUR RENVOYÉE
       En cas de succès, zéro est renvoyé. En cas d'erreur, -1 est renvoyé et
       errno reçoit une valeur adéquate.

       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 actuelle 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 non valable.

       EPERM  Une tentative a été opérée pour ajouter une capacité dans
              l'ensemble permitted, ou pour placer une capacité dans l'ensemble
              effective hors de l'ensemble permitted.

       EPERM  Une tentative a été faite pour ajouter une capacité dans
              l'ensemble inheritable et soit :

              *  cette capacité n'était pas présente dans l'ensemble applicable
                 à l'appel ; soit

              *  cette capacité n'était pas dans l'ensemble permitted pour
                 l'appel et l'appelant n'avait pas de capacité CAP_SETPCAP dans
                 son ensemble effectif.

       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 des
              capacités VFS, ce n'est jamais permis. Pour les noyaux sans la
              gestion des capacités VFS, 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.gitVOIR AUSSI
       clone(2), gettid(2), capabilities(7)

COLOPHON
       Cette page fait partie de la publication 5.08 du projet man-pages Linux.
       Une description du projet et des instructions pour signaler des anomalies
       et la dernière version de cette page, peuvent être trouvées à l'adresse
       https://www.kernel.org/doc/man-pages/.


TRADUCTION
       La traduction française de cette page de manuel a été créée par
       Christophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin
       <stephan.rafin@laposte.net>, Thierry Vignaud <tvignaud@mandriva.com>,
       François Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe
       Guérard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-
       luc.coulon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas
       Huriaux <thomas.huriaux@gmail.com>, Nicolas François
       <nicolas.francois@centraliens.net>, Florentin Duneau <fduneau@gmail.com>,
       Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis Barbier
       <barbier@debian.org>, David Prévot <david@tilapin.org>, Cédric Boutillier
       <cedric.boutillier@gmail.com>, Frédéric Hantrais <fhantrais@gmail.com> et
       Jean-Philippe MENGUAL <jpmengual@debian.org>

       Cette traduction est une documentation libre ; veuillez vous reporter à
       la GNU General Public License version 3 concernant les conditions de
       copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si vous découvrez un bogue dans la traduction de cette page de manuel,
       veuillez envoyer un message à <debian-l10n-french@lists.debian.org>.



Linux                            9 février 2020                        CAPGET(2)