Tu m'explique déjà comment tu donnes des privilèges différent au sein du _même_ processus, que ce processus soit géré par le noyau ou la vm ?
En Java, la VM est capable d'analyser la pile d'appel et de déterminer l'origine du code qui tente d'effectuer une opération privilégiée (comme l'accès à un fichier) À coté de ça, elle pourra avoir un fichier de politique de sécurité, indiquant quel code possède quelles permissions. Si du code "non-trusted" (du code télécharger sur Internet, par exemple) tente d'effectuer une opération sans y être explicitement autorisé, il y aura une exception. Mais à côté de ça, le code "trusted" (fourni par l'application) pourra avoir des permissions plus souples.
Par défaut, ce mécanisme est désactivé (n'importe quel code peut faire n'importe quoi), mais ça s'active et s'utilise très facilement.
Même chose si tu lance ton applet avec ou les bonnes règles selinux et/ou setuid=nobody
Non, parce que l'environnement d'exécution pourra avoir besoin d'accéder à des fichiers locaux (un fichier de préférences, par exemple), mais on voudra quand même empêcher l'applet de lire quoi que ce soit sur le disque local. C'est possible parce qu'on peut donner des permissions différentes aux classes de base et à celles téléchargées.
[^] # Re: Pourquoi Mono ?
Posté par Buf (Mastodon) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
Tu m'explique déjà comment tu donnes des privilèges différent au sein du _même_ processus, que ce processus soit géré par le noyau ou la vm ?
En Java, la VM est capable d'analyser la pile d'appel et de déterminer l'origine du code qui tente d'effectuer une opération privilégiée (comme l'accès à un fichier) À coté de ça, elle pourra avoir un fichier de politique de sécurité, indiquant quel code possède quelles permissions. Si du code "non-trusted" (du code télécharger sur Internet, par exemple) tente d'effectuer une opération sans y être explicitement autorisé, il y aura une exception. Mais à côté de ça, le code "trusted" (fourni par l'application) pourra avoir des permissions plus souples.
Par défaut, ce mécanisme est désactivé (n'importe quel code peut faire n'importe quoi), mais ça s'active et s'utilise très facilement.
Même chose si tu lance ton applet avec ou les bonnes règles selinux et/ou setuid=nobody
Non, parce que l'environnement d'exécution pourra avoir besoin d'accéder à des fichiers locaux (un fichier de préférences, par exemple), mais on voudra quand même empêcher l'applet de lire quoi que ce soit sur le disque local. C'est possible parce qu'on peut donner des permissions différentes aux classes de base et à celles téléchargées.