Provided by:
manpages-fr-dev_3.27fr1.4-1_all 
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> >>.