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