2008-11-17 4 views

Répondre

4

Cela n'a pas beaucoup de sens. Que faire si le code (malveillant ou non) provoque l'exécution sur un thread différent? Cela peut même arriver dans la bibliothèque Java, avec le contexte de sécurité transféré (qui peut utiliser java.security.AccessController.getContext/doPrivileged).

Les applets utilisent un système légèrement difficile impliquant ThreadGroup s, mais je ne le recommanderais pas. JAAS permet d'ajouter un Subject au AccessControlContext, mais personnellement, je suggère de ne pas utiliser ce style de programmation.

Donnez au code téléchargé (le cas échéant) les autorisations appropriées et ne donnez pas d'objets sensibles au code avec lequel vous ne leur faites pas confiance.

+0

En fait, nous avons eu un problème d'architecture. Notre application fonctionne avec les privilèges de root et crée un thread par tâche. Cette tâche doit avoir des droits spécifiques en fonction de l'utilisateur. – Creasixtine

+0

La solution que nous avons prise a été d'étendre un RMISecurityManager et d'utiliser JNI. Cela fonctionne bien avec une variable ThreadLocal. Mais le problème est qu'il ne fonctionne pas avec les threads créés automatiquement, comme ceux créés lors de la création des sockets. – Creasixtine

+0

Pour cela je voudrais un gestionnaire de sécurité pour tout, et un pour les tâches des threads ... si c'était possible ... – Creasixtine

2

SecurityManager effectue des vérifications basées sur le contexte de sécurité du thread en cours d'exécution, peut-être voulez-vous que votre SecurityManager se comporte différemment en fonction de ce qu'il trouve dans le contexte?

Ou peut-être, vous souhaitez implémenter votre SecurityManager en utilisant le modèle de stratégie.

yc