Envoyé par _Mac_
Décris-nous ton archi : d'un côté tu as l'utilisateur devant son PC qui parle avec un serveur J2EE. On est en train de voir comment ce serveur J2EE peut exécuter des commandes Shell. On est bien d'accord ?
La commande qui sera appelée par le serveur J2EE avec Runtime.getRuntime().exec("<commande>") quelque soit <commande>, que ce soit un rsh, un ls ou autre chose, sera exécuté sur le serveur en tant qu'utilisateur qui fait tourner le serveur J2EE. Par exemple, si ton serveur J2EE est un Tomcat et qu'il a été démarré avec l'utilisateur système apache, c'est l'utilisateur apache qui invoquera la commande.
Du coup, il faut t'assurer de plusieurs choses :
- Qui (i.e. quel utilisateur système) doit exécuter le script shell ? Il y a éventuellement une problématique de mot de passe/connexion authentifiée à gérer. Voir les 2 points suivants. Dans tous les cas, il faut éviter au maximum d'avoir à manipuler un mot de passe, pour des problèmes de sécurité mais aussi pour des raisons de simplicité : si le mot de passe change, c'est pas mal si on peut éviter d'avoir à reconfigurer l'appli.
- Si le script shell a exécuté se trouve sur le serveur J2EE, l'utilisateur apache peut-il correctement exécuter la commande (pour tester, il faut se connecter sur le serveur avec l'utilisateur apache et exécuter la commande). Si c'est un autre utilisateur qu'apache qui doit exécuter le script, faut installer et utiliser une "passerelle" du type sudo qui t'éviteras d'avoir à stocker et synchroniser un mot de passe.
- Si le script shell se trouve sur une autre machine, il faut effectivement utiliser rsh pour l'invoquer. Avec rsh, il est possible de passer un utilisateur différent, et ce qui est bien, c'est qu'une fois bien configuré, tu n'as plus besoin de passer de mot de passe. Mais il faut bien le configurer (par défaut, faut un mot de passe).
Dans tous les cas, il faut se poser la question de la sécurité : faire en sorte que seules les personnes habilitées peuvent invoquer la commande shell. Ca, ça se fait plutôt par ton application Web. Eviter par exemple de faire passer la commande à exécuter dans l'URL. Ca vaut même pour une application interne.
Bon courage.