Discussion :

[F2S]

Bonjour à tous,


Mon soucis est que je voudrai lancer des commandes systèmes ou des scripts shell à partir de mon code java.
J'ai bien qqs idées, mais rien de tres claire...

donc si qqn aurait une idée "lunimeuse" pour éclairé, je lui en serais reconnaissant

Merci d'avance

[thibaut]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Runtime.getRuntime().exec("<commande>");

[F2S]

Merci pour la rapidité...

je pensais bien qu'il fallait utilisé "java.lang.Runtime", mais je ne me pensais pas que c'était aussi simple...

je vais tester merci

[F2S]

Cool hé bien ça fonctionne bien, par contre une petite chose à dire pour ce qui tomberaient sur cette discussion.

si vous voulez executer un fichier ".bat", il faut mettre le chemin complet avec deux "\" au lieu d'un.
exemple : D:\\tmp\\test.bat

et pour les fichier shell et compagnie, je pense que la syntaxe devrait être :
"D:/tmp/test.sh" ( à vérifier )

[F2S]

que de précision.

Les bonnes pratiques pour exécuter une application externe.

[F2S]

Comment faire pour récupérer le resultat de la commande ?

[thibaut]

Quand tu fait Runtime.getRuntime.exec(); tu récupère un objet de type Process.

Et tu dois faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Process process = Runtime.getRuntime.exec();
InputStream in = process.getInputStream();

Et lire sur le flux InputStream...

[diamonds]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Runtime.getRuntime().exec("<commande>");

Bonjour

Moi j'ai une application web (Java avec Netbeans + VWP).
Au click d'un bouton sur ma page web, je veux qu'un fichier shell soit lançé.

Ce fichier shell se trouve sur un serveur de fichier Unix qui est accessible par le réseau local.

Comment alors la commande Runtime.getRuntime().exec("<commande>") saurait que moi je parle de ce serveur de fichier unix ?

Merci.

[iohack]

Bonjour

Moi j'ai une application web (Java avec Netbeans + VWP).
Au click d'un bouton sur ma page web, je veux qu'un fichier shell soit lançé.

Ce fichier shell se trouve sur un serveur de fichier Unix qui est accessible par le réseau local.

Comment alors la commande Runtime.getRuntime().exec("<commande>") saurait que moi je parle de ce serveur de fichier unix ?

Merci.

Runtime.getRuntime().exec("rsh [paramètres] commande") ;

[diamonds]

Runtime.getRuntime().exec("rsh [paramètres] commande") ;

à quelle place ? dans l'évenement OnClick du bouton à cliquer ?

[*alexandre*]

J espere que command n'est pas un paramètre de ta page web, executé des commandes systèmes depuis une page web n est vraiment pas secure

prévois bien la définition de rôle pour chacun des users

[diamonds]

J espere que command n'est pas un paramètre de ta page web, executé des commandes systèmes depuis une page web n est vraiment pas secure

Les utilisateurs n'ont pas accès à l'internet. C'est juste des employés interne qui vont le faire sur l'intranet.

Qu'est ce que tu veux dire par

prévois bien la définition de rôle pour chacun des users

[diamonds]

Runtime.getRuntime().exec("rsh [paramètres] commande") ;

Si par exemple je veux lancer sur la ligne de commande de unix la commande suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
>ls -l

est ce que les instructions java seront :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 Runtime.getRuntime().exec("rsh -l ls") ;

ou bien comme Thibaut a dit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Runtime.getRuntime().exec("<commande>");
 
Runtime.getRuntime().exec("ls -l");

Est-ce que ça prend une classe ou une bibliothèque qu'il faut importer ?

[STB_Fk]

Bonjour,

Normalement pas d'import a réaliser pour utiliser ces fonctions.

Par :

prévois bien la définition de rôle pour chacun des user

Il veut dire que si n'importe quel utilisateur peut executer une commande qui est passé en parametre d'une page web, c'est super dangeraux surtout dans un milieu professionel. Ex : un rm * lancé sur ton serveur ne sera pas vraiment du plus belle effet. C'est pour cela que tu dois autoriser les commandes qu'a des utilisateurs de confiances si elles sont passé en paramètres. Mais vaut mieux éviter de donner de telles possibilités aux users.

Fk

[diamonds]

Bonjour,

Normalement pas d'import a réaliser pour utiliser ces fonctions.

Par :


Il veut dire que si n'importe quel utilisateur peut executer une commande qui est passé en parametre d'une page web, c'est super dangeraux surtout dans un milieu professionel. Ex : un rm * lancé sur ton serveur ne sera pas vraiment du plus belle effet. C'est pour cela que tu dois autoriser les commandes qu'a des utilisateurs de confiances si elles sont passé en paramètres. Mais vaut mieux éviter de donner de telles possibilités aux users.

Fk

Mais je présume que ce type de sécurité est déjà fait au niveau du système unix.

java ne peut pas (je pense) modifier ces permissions pour qu'un user puisse les utiliser de manière frauduleuse.
Est-ce que je me trompe ?

[STB_Fk]

Je pense que si!
Quel utilisateur utilise tu pour executer ta commande unix??
Si tu peux gérer des droits directement avec Java c'est pas plus mal.
Après tout dépend de la confiance que tu as dans les users

Fk

[_Mac_]

Ce fichier shell se trouve sur un serveur de fichier Unix qui est accessible par le réseau local.

Comment alors la commande Runtime.getRuntime().exec("<commande>") saurait que moi je parle de ce serveur de fichier unix ?

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 ?

java ne peut pas (je pense) modifier ces permissions pour qu'un user puisse les utiliser de manière frauduleuse.
Est-ce que je me trompe ?

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.

[diamonds]

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.

Salut mac

à la lecture de ton message, j'ai eu beaucoup d'autres idées.

voici l'architecture :

L'utilisateur lance l'application sur son pc à partir d'un lien (dans l'intranet)
Le serveur appelons le A

A est un serveur de fichier unix (solaris) qui contient aussi un serveur web apache et un serveur web tomcat.

A contient aussi le script shell que je veux éxécuter

A contiendra aussi les fichiers qui seront crées à l'exécution du script shell.

Maintenant moi je veux que au lancement de cette application web, lorsque l'utilisateur click sur un bouton, le script sur la machine A soit lançé.

Oui la machine A est accessible par un userid et un mot de passe.

Je veux que ce script peut être lançé à partir de l'application web et je me suis dit qu'il faut biensur mettre un userid et un mot de passe dans l'application java capable de lancer ce script mais sans plus.

mais lorsque je déploi l'application, le code source de l'application ne va pas être visible normalement étant donné qu'on donne jsute le .war (ou les .jar). Est-ce que c'est vrai ?

Le code source de l'application sera la possession de l'administrateur du système seulement.

Qu'est ce que t'en pense ? ya t-il d'autres choses auxquels je dois faire atention ?

dans ce cas, faut-il utiliser rsh ou non ?

Je ne comprends pas ce passage dans les utilisateurs

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.

[_Mac_]

Oui la machine A est accessible par un userid et un mot de passe.

Je veux que ce script peut être lançé à partir de l'application web et je me suis dit qu'il faut biensur mettre un userid et un mot de passe dans l'application java capable de lancer ce script mais sans plus.

[...]

Je ne comprends pas ce passage dans les utilisateurs

Pour le moment, oublie le userid/password : tu nous dis que le script est sur la même machine que Tomcat, donc y a peut-être moyen de ne pas s'occuper de ça.

Sur un serveur, quelque soit l'OS, les programmes fonctionnent avec un certain utilisateur : l'utilisateur qui a démarré le programme. Quand on démarre Tomcat, on se connecte bien sur la machine avec un utilisateur (je prenais l'exemple de l'utilisateur "apache") et on tappe la commande de démarrage de Tomcat. C'est cet utilisateur qui fait tourner Tomcat. La JVM de Tomcat tourne donc sur le serveur en tant que cet utilisateur (apache dans mon exemple). Donc tout ce que fait Tomcat et ton programme se fait sur le serveur en tant qu'apache, y compris le lancement de ton script shell avec Runtime.exec(). Pour que ton truc marche, il faut donc s'assurer que l'utilisateur apache peut exécuter ce script shell et que script fonctionnera alors correctement.

Au passage, si l'utilisateur que vous utilisez réellement pour lancer Tomcat est root (à la place de apache), c'est pas top du tout du tout du tout. Pourquoi ? Parce que ton script sera appelé en tant que root, donc en tant que super utilisateur et donc potentiellement il peut tout faire, y compris des bêtises. C'est d'autant plus dangereux si le chemin du script à exécuter apparaît qq part dans les URL. Dans ce cas, pour déconner, un gars peut appeler la commande rm ou je ne sais quoi d'autre et là, c'est la merde. C'est pour ça qu'il faut super bien protéger ton appli et faire en sorte que le nom du script n'apparaisse nulle part.

mais lorsque je déploi l'application, le code source de l'application ne va pas être visible normalement étant donné qu'on donne jsute le .war (ou les .jar). Est-ce que c'est vrai ?

Oui, c'est juste, mais ça ne change rien au problème. Tu ne livres pas le script dans ton war, si ? Dans ce cas, je ne suis pas sûr que tu puisses faire fonctionner ton script car il manquera vraisemblablement le flag x (exécutable) sur ton script.

Du coup, le mieux je pense est de livrer ton appli Tomcat dans un war et de livré ton script shell à part. Dans ta procédure de livraison, tu dis bien évidemment d'installer le war dans Tomcat et de copier le shell dans un certain répertoire du serveur. Il faut que ce répertoire soit un paramètre de ton application Tomcat de manière à pouvoir le paramétrer sans avoir à modifier le code de ton appli. Il te suffit alors de récupérer ce répertoire dans ton appli et de l'utiliser dans ton Runtime.exec() pour construire le chemin complet vers ton script. A la limite, ton paramètre est ce chemin complet (/rep1/rep2/script.sh) comme ça, y a pas de pb si le nom du script change.

Le code source de l'application sera la possession de l'administrateur du système seulement.

Si tu veux...

dans ce cas, faut-il utiliser rsh ou non ?

Non dans la mesure où le script se trouve sur la même machine que le serveur Tomcat. rsh c'est uniquement dans le cas où le script se trouve sur une autre machine que le serveur Tomcat.

[diamonds]

Pour que ton truc marche, il faut donc s'assurer que l'utilisateur apache peut exécuter ce script shell et que ce script fonctionnera alors correctement.

Comment puis-je vérifier si l'utilisateur apache peut exécuter ce script ? est-ce l'essayer avec un classique http://..... ?

Au passage, si l'utilisateur que vous utilisez réellement pour lancer Tomcat est root (à la place de apache), c'est pas top du tout du tout du tout. Pourquoi ? Parce que ton script sera appelé en tant que root, donc en tant que super utilisateur et donc potentiellement il peut tout faire, y compris des bêtises.

Comment l'administrateur du système peut vérifier si c'est le root qui lance Tomcat ou si c'est un autre utilisateur ?

C'est d'autant plus dangereux si le chemin du script à exécuter apparaît qq part dans les URL. Dans ce cas, pour déconner, un gars peut appeler la commande rm ou je ne sais quoi d'autre et là, c'est la merde. C'est pour ça qu'il faut super bien protéger ton appli et faire en sorte que le nom du script n'apparaisse nulle part.

Non, le chemin du script ne dois pas apparaitre dans les URL, parcontre il va se trouver quelque part dans le code source de l'application. en l'occurence la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Runtime.getRuntime().exec...

Oui, c'est juste, mais ça ne change rien au problème. Tu ne livres pas le script dans ton war, si ? Dans ce cas, je ne suis pas sûr que tu puisses faire fonctionner ton script car il manquera vraisemblablement le flag x (exécutable) sur ton script.

Je ne comprends pas ce que tu veux dire par le flag x. ce script je lui donnerais les droits d'exécution suivants : x pour le owner, pour le groupe, et aussi pour les autres. Alors tout le monde aura le droit d'éxécuter ce script, mais s'ils veulent déconner, ils doivent d'abord passer par un userid et un mot de passe pour ouvrir la connexion avec le serveur. Ce userid et ce mot de passe vont se trouver quelques part dans le code source. à moins que après la connexion, pour une raison ou une autre, l'application se break au milieu, et l'utilisateur se retrouvera directement devant la ligne de commande de ce serveur.

Il faut que ce répertoire soit un paramètre de ton application Tomcat de manière à pouvoir le paramétrer sans avoir à modifier le code de ton appli. Il te suffit alors de récupérer ce répertoire dans ton appli et de l'utiliser dans ton Runtime.exec() pour construire le chemin complet vers ton script. A la limite, ton paramètre est ce chemin complet (/rep1/rep2/script.sh) comme ça, y a pas de pb si le nom du script change.

Pas sur de bien comprendre ici.
Supposons que mon .war se trouve sur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/machin/webapps/monapplication.war

et le script shell se trouve sur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/rep1/rep2/script.sh

Est-ce que la ligne java qui va lancer le script sera de la forme suivante ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Runtime.getRuntime().exec("/rep1/rep2/script.sh");

si oui, si un jour le nom du script change ou bien si son emplacement change, on va devoir faire des modifications dans cette ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Runtime.getRuntime().exec("/rep1/rep2/script.sh");

pour moi : parametre = "/rep1/rep2/script.sh" est-ce exact ?
il y a quelque chose que j'échappe.

Diamonds