on parlait de ressources partagées en utilisant les méccanismes kernels de séparation de privilèges
Il est évident que les shm permettent à 2 processus P1 et P2 de communiquer via des variables partagées tout en protégeant les variables privées de P1 et P2.
Par conséquent si P1 est malicieux, il ne pourra pas accéder aux variables privées de P2 pour détourner les privilèges de P2 sur la ressource R non partagée (par exemple R est un fichier accessible uniquement à P2).
Ceci étant ma définition (pas que la mienne) de séparation de privilèges. Un privilège étant, par définition, une ressource qui n'est pas partagée par tous.
Tu retrouves ce système de séparation (avec communications par shm ou pipes ou sockets) dans de nombreux softs Unix sécurisés.
Tu ne peux pas faire cela pour R avec des threads T1 et T2 appartenants au meme process. Il n'y a donc pas de séparation de privilèges possible avec les threads.
[^] # Re: Séparation des privilèges impossible avec threads actuelles !
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Il est évident que les shm permettent à 2 processus P1 et P2 de communiquer via des variables partagées tout en protégeant les variables privées de P1 et P2.
Par conséquent si P1 est malicieux, il ne pourra pas accéder aux variables privées de P2 pour détourner les privilèges de P2 sur la ressource R non partagée (par exemple R est un fichier accessible uniquement à P2).
Ceci étant ma définition (pas que la mienne) de séparation de privilèges. Un privilège étant, par définition, une ressource qui n'est pas partagée par tous.
Tu retrouves ce système de séparation (avec communications par shm ou pipes ou sockets) dans de nombreux softs Unix sécurisés.
Tu ne peux pas faire cela pour R avec des threads T1 et T2 appartenants au meme process. Il n'y a donc pas de séparation de privilèges possible avec les threads.