01
Traiter un seul ensemble
Une valeur seule ou CapEff: 0000000000000003 est acceptée. Même composée uniquement de chiffres, l’entrée reste hexadécimale : 10 vaut 16 en décimal. Analysez les différents ensembles séparément.
Linux & Shell
Décoder les capabilitiesavec le détail de chaque bit
Collez un masque ou une seule ligne Cap de /proc. Consultez les noms, puis préparez une autre combinaison en cochant les bits connus.
Décoder les capabilities
Composer un masque par noms
Décodez d’abord une valeur valide. Chaque case ouvre l’aperçu d’un seul bit modifié ; les bits sans nom sont conservés.
Capabilities décodées
La valeur collée est traitée dans ce navigateur, sans lire votre système ni envoyer la saisie à un serveur.
Interprétation et export
Tables UAPI figées : aucun détecteur de noyau ni simulation de ses contrôles de permissions.
Le résultat est périmé. Décodez avant de modifier les bits ou d’exporter.
Décoder les capabilities permet de lire les longues valeurs hexadécimales d’un état de processus. Gardez CapEff ou CapBnd avec le nombre : deux valeurs identiques peuvent désigner des ensembles dont le rôle est différent.
L’exemple active 14 capabilities nommées. Il illustre une notation, sans représenter les permissions de votre machine ni une configuration universelle des conteneurs. La source du champ compte autant que les noms affichés.
Décoder les capabilities sans perdre de bits
Une table interprète la valeur ; elle ne la remplace pas.
Relier les positions aux noms
Décoder les capabilities associe chaque bit actif à un nom CAP_* et à une explication courte. Cocher une case ouvre d’abord la comparaison entre les deux masques et indique le bit concerné, avant toute modification du texte source.
Reconnaître les ajouts entre versions
Un bit sans nom dans la table 3.16 peut être reconnu dans la table 5.9. Le changement de table conserve le nombre entier, y compris les positions hautes jusqu’à 63. Un nom absent ne devient jamais une autorisation à effacer le bit.
Vérifier le champ avant de modifier sa valeur
02
Choisir un dictionnaire de noms
Les instantanés 3.16, 5.8 et 5.9 s’arrêtent respectivement aux bits 37, 39 et 40. Ils ne détectent pas votre noyau. Les rétroportages d’une distribution et les règles effectivement exécutées restent à vérifier sur la cible.
03
Relire l’aperçu
Les cases ne sont actives que pour un résultat valide et à jour. Appliquer met à jour source et résultat ensemble ; le retour arrière restaure le texte précédent, champ compris. Le mode manuel accepte aussi Ctrl/Cmd + Entrée.
Des valeurs exactes et des noms contextualisés
Un entier non signé sur 64 bits
Les capabilities Linux sont ici lues comme un masque, sans approximation flottante. Le résultat présente 16 chiffres hexadécimaux minuscules et 64 chiffres binaires. Le masque et la valeur décimale restent des chaînes dans le rapport JSON.
Une notice par capacité reconnue
Chaque entrée porte son numéro et un résumé de son usage. CAP_NET_BROADCAST est explicitement inutilisée. Les positions que le dictionnaire ne connaît pas sont énumérées séparément au lieu de recevoir un nom supposé.
Un rapport qui garde sa provenance
Les exports texte et JSON conservent la table choisie et l’étiquette CapEff ou tout autre champ reconnu. Tous les bits actifs y figurent. Comparer avec capsh reste possible ; le rapport texte n’est pas une expression de configuration pour setcap.
Ce que la lecture d’un masque ne décide pas
- Syntaxe hexadécimale bornée
- Saisissez de 1 à 16 chiffres ASCII, éventuellement précédés de 0x ou 0X. Les espaces extérieurs sont ignorés. La limite totale est de 256 unités UTF-16 ; signes, séparateurs et dépassements sont rejetés sans tronquer la valeur.
- Pas de mélange de champs
- CapInh, CapPrm, CapEff, CapBnd et CapAmb sont reconnus avec deux-points. Le fichier status complet, plusieurs lignes de contenu, les listes de noms et les expressions +ep sont refusés. Aucun import de PID, fichier ou URL n’est proposé.
- Aucune simulation des permissions
- L’outil ne reproduit ni execve, ni les espaces de noms, securebits, seccomp ou LSM. Une seule valeur ne permet pas de déduire les permissions minimales d’un programme, le mode privilégié d’un conteneur ou sa sécurité.
- Les positions inconnues restent intactes
- Seuls les bits ayant un nom dans la table sont modifiables. Les autres restent dans le masque et dans l’export, même après le choix d’une ancienne table. Pas de sélection globale, d’effacement de bits inconnus ni de génération de commandes d’attribution.
- Un résultat périmé ne se copie pas
- Modifier la source ou la table désactive immédiatement l’export. Le traitement automatique attend 350 ms et son arrêt annule le travail en attente. Exemple, effacement et modification d’un bit passent par un aperçu puis une application, avec un retour arrière.
Décoder les capabilities : vos questions
Que signifient CapInh, CapPrm et CapEff dans l’état du processus ?
Ces champs décrivent des ensembles distincts : héritables, permis et effectifs. CapBnd représente la borne et CapAmb l’ensemble ambiant. Un même numéro de bit conserve son nom, mais le rôle du champ change. Cette page lit un ensemble à la fois, sans calculer leurs transitions.
Que signifie +ep lors de l’attribution de capabilities ?
Dans la notation libcap, p concerne les capacités permises et e l’état effectif. Les capabilities de fichiers possèdent un drapeau effectif utilisé lors de l’exécution. Une expression comme cap_net_raw+ep n’est pas un masque hexadécimal et ne se colle pas dans cet outil.
Comment examiner les capabilities d’un processus ?
Sur l’hôte Linux cible, consultez les champs Cap de /proc/PID/status ou utilisez getpcaps si disponible. Collez ensuite une ligne ici. Le navigateur n’interroge pas le processus, et cette lecture n’indique pas à elle seule les permissions minimales nécessaires.
Comment savoir quelles capabilities un programme exige ?
Il faut distinguer ce que le programme détient de ce dont ses opérations ont besoin. Examinez sa documentation et son fonctionnement, puis observez des charges représentatives dans un environnement contrôlé. Aucun traçage ni conseil d’attribution minimale n’est fourni ici.
Pourquoi les capacités permises ne sont-elles pas toutes effectives ?
L’ensemble permis borne ce que le thread peut activer dans son ensemble effectif. Ce dernier sert aux vérifications de capabilities. Une capacité peut donc être conservée sans être active à cet instant ; les transitions d’exécution obéissent à des règles supplémentaires.
Une autre question ?
Lire un autre ensemble
Décoder les capabilities conserve le champ d’origine. Vérifiez les noms et les positions inconnues, puis exportez le rapport correspondant à votre lecture.
Un décodage correct ne garantit pas une configuration sûre.