Executé un script Shell en root

Fermé
El_Diablo666 Messages postés 294 Date d'inscription jeudi 8 février 2007 Statut Membre Dernière intervention 3 décembre 2012 - Modifié par El_Diablo666 le 16/01/2012 à 15:00
El_Diablo666 Messages postés 294 Date d'inscription jeudi 8 février 2007 Statut Membre Dernière intervention 3 décembre 2012 - 23 févr. 2012 à 15:36
Bonjour,

Je réalise une interface pour pouvoir lancer des script distant sur mon serveur dédié qui tourne sous Debian 5.0.

Une interface Web sur serveur A avec formulaire qui à la validation se connecte en SSH sur un serveur B exécute un script en lui passant des paramétrés.

Le tous fonctionne parfaitement (Authentification, passage des paramètres, lancement du script).

le problème c'est qu'il existe dans ce script des commandes qui ne peuvent se faire qu'on mode "root" comme la création de fichiers dans des répertoires avec "root" comme Owner et pas la possibilité de les changés.

Ma question donc: comment lancer le script a chaque appel en "root"?



Merci pour toutes info utiles.


A voir également:

3 réponses

IvyAlice Messages postés 379 Date d'inscription lundi 17 septembre 2007 Statut Membre Dernière intervention 14 septembre 2013 32
16 janv. 2012 à 16:28
Je ne lancerais pas le scripte en root, mais éventuellement accordé sur le serveur où il a besoin les droits de faire un sudo (ou la commande qu'il a à faire) sans mot de passe avec.
Pour ça il faut configurer en tapant visudo
un exemple :
Si je ne me trompe pas, autorise l'utilisateur www-data à lancé la commande ssh depuis la machine hellraiser en tant que l'user read.
1) visudo
www-data hellraiser=(read) NOPASSWD:/usr/bin/ssh

Par contre je ne sais pas si c'est la meilleurs solution, il en existe sûrement d'autres.

Ivy
0
mamiemando Messages postés 32948 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 22 février 2024 7 722
Modifié par mamiemando le 17/01/2012 à 19:55
La solution d'IvyAlice me paraît bien, car comme le montre la syntaxe qu'elle te propose tu peux faire en sorte qu'un sudoers n'ait pas systématiquement des droits root pour toutes les commandes, ce qui limite les éventuels risques d'une telle approche. Il faut juste installer le paquet sudo au préalable et le configurer avec la commande :

visudo -s


Tu as également des modules comme suphp avec apache qui pourraient répondre à ton besoin, comme celui-ci si tu utilises apache :

libapache2-mod-suphp - Apache2 module to run php scripts with the owner permissions


Mais dans ton cas précis je pense que l'approche la plus sûre dans ce cas de figure c'est plutôt de privilégier une solution basée purement sur ssh...

En tout cas, permettre l'upload de scripts qui peuvent contenir a priori lancés avec des droits root, ça me paraît risqué à première vue. Notamment si le site n'est pas en https, qu'on sniffe ton mot de passe et qu'on commence à faire n'importe quoi avec ton interface. Et je ne parle pas des attaques basées sur des injections, ou des fausses manipulations...

Qu'est ce que tu cherches à faire plus précisément ?

Bonne chance
0
El_Diablo666 Messages postés 294 Date d'inscription jeudi 8 février 2007 Statut Membre Dernière intervention 3 décembre 2012 32
Modifié par mamiemando le 23/02/2012 à 23:34
Merci pour votre réponse, je suis en train de faire une sorte de Cpanel pour la gestion de mes sites web sur un serveur dédié sans passer par la console SSH et en plus j'aimerais déléguer la tâche de création des sites web directement à mon équipe commerciale, donc ma création se fait sans passer par moi que je représente l'équipe technique. Pour vous mettre un peu dans le bain :

- Le serveur dédié est accessible via SSH depuis nos locaux avec une restriction par IP (la notre) sur cette accès chez l'hébergeur du serveur.
- Le serveur hébergeant l'interface faite en PHP est hébergé dans mes locaux et il n'est pas visible via Internet.
- Le serveur de l'application PHP lance les scripts via SSH sur le serveur dédié.

Je pense que de cette façon je n'aurai pas à avoir peur d'attaque de l'extérieur.

Si vous avez d'autres solutions à me proposer, car je souhaiterais élargir cette solution un jour et la rendre accessible en ligne pour mes clients par exemple.
0