Un programme en mode capacité ne peut pas "récupérer des droits" de lui-même. La seule façon d'acquérir des droits qu'il n'a pas (ou "plus"), c'est si un autre programme (qui a des droits pour le faire) lui passe des capacités supplémentaires.
Pour un exemple concret, l'exemple du "choix de fichier" : le programme en mode capacité envoie un message à un outil système (ou plutôt de l'environnement de bureau) nommé PowerBox (ou, dans Capsicum, "user rights angel") pour lui demander de proposer un choix de fichier à l'utilisateur. Il lui indique aussi quels droits il réclame sur le fichier ouvert (lecture, écriture, etc.). La PowerBox tourne déjà avec les droits d'accès au système de fichiers, que le programme n'a pas; il propose le choix du fichier à ouvrir à l'utilisateur (en essayant de lui indiquer clairement quels droits il concède sur le fichier choisi), ouvre un descripteur de fichier avec les droits demandés (ce descripteur est précisément une "capacité"), et passe cette capacité au programme initial, qui peut continuer son travail en ayant acquis ce "nouveau droit".
On peut imaginer la même chose, non dans le cadre d'une interface graphique, mais pour un shell. Actuellement le programme cp a besoin pour fonctionner de l'accès à tout le système de fichier, en lecture comme en écriture; en effet, quand on invoque cp foo bar, il doit transformer le chemin foo en fichier ouvert en lecture et le chemin bar en fichier ouvert en écriture. Plus généralement toutes les commandes qui prennent en argument un chemin doivent avoir les même droits que l'utilisateur sur le système de fichier.
Mais on peut mettre en place une organisation des programme plus économe en droit. Quand on écrit cat foo > bar, ce n'est plus le programme qui ouvre bar en lecture, mais le shell, qui s'en occupe et passe le descripteur vers bar en sortie standard quand il invoque cat. On peut imaginer une commande cp$ qui prenne en paramètres non pas deux chemins, mais deux descripteurs (un en lecture et un en fermeture). Pour invoquer cette commande il faudrait un shell au courant de cette spécificité, qui aurait par exemple la convention que les arguments de la forme =path et +path (par exemple +/tmp/foo.txt) ne sont pas envoyées sous forme de chaîne de caractères au programme, mais sous forme de descripteurs ouverts respectivement en lecture et en écriture. On invoquerait alors cp$ =foo +bar. Dans ce cas de figure, c'est le shell qui joue le rôle de "programme privilégié transmettant ses droits" (powerbox), et qui permet aux programmes invoqués de mieux respecter le Principle of Least Authority, en étant organisés de façon à nécessiter moins de droits.
[^] # Re: pas compris
Posté par gasche . En réponse à la dépêche Capsicum, une séparation fine des privilèges pour UNIX. Évalué à 10.
Un programme en mode capacité ne peut pas "récupérer des droits" de lui-même. La seule façon d'acquérir des droits qu'il n'a pas (ou "plus"), c'est si un autre programme (qui a des droits pour le faire) lui passe des capacités supplémentaires.
Pour un exemple concret, l'exemple du "choix de fichier" : le programme en mode capacité envoie un message à un outil système (ou plutôt de l'environnement de bureau) nommé PowerBox (ou, dans Capsicum, "user rights angel") pour lui demander de proposer un choix de fichier à l'utilisateur. Il lui indique aussi quels droits il réclame sur le fichier ouvert (lecture, écriture, etc.). La PowerBox tourne déjà avec les droits d'accès au système de fichiers, que le programme n'a pas; il propose le choix du fichier à ouvrir à l'utilisateur (en essayant de lui indiquer clairement quels droits il concède sur le fichier choisi), ouvre un descripteur de fichier avec les droits demandés (ce descripteur est précisément une "capacité"), et passe cette capacité au programme initial, qui peut continuer son travail en ayant acquis ce "nouveau droit".
On peut imaginer la même chose, non dans le cadre d'une interface graphique, mais pour un shell. Actuellement le programme
cpa besoin pour fonctionner de l'accès à tout le système de fichier, en lecture comme en écriture; en effet, quand on invoquecp foo bar, il doit transformer le cheminfooen fichier ouvert en lecture et le cheminbaren fichier ouvert en écriture. Plus généralement toutes les commandes qui prennent en argument un chemin doivent avoir les même droits que l'utilisateur sur le système de fichier.Mais on peut mettre en place une organisation des programme plus économe en droit. Quand on écrit
cat foo > bar, ce n'est plus le programme qui ouvrebaren lecture, mais le shell, qui s'en occupe et passe le descripteur versbaren sortie standard quand il invoquecat. On peut imaginer une commandecp$qui prenne en paramètres non pas deux chemins, mais deux descripteurs (un en lecture et un en fermeture). Pour invoquer cette commande il faudrait un shell au courant de cette spécificité, qui aurait par exemple la convention que les arguments de la forme=pathet+path(par exemple+/tmp/foo.txt) ne sont pas envoyées sous forme de chaîne de caractères au programme, mais sous forme de descripteurs ouverts respectivement en lecture et en écriture. On invoquerait alorscp$ =foo +bar. Dans ce cas de figure, c'est le shell qui joue le rôle de "programme privilégié transmettant ses droits" (powerbox), et qui permet aux programmes invoqués de mieux respecter le Principle of Least Authority, en étant organisés de façon à nécessiter moins de droits.