qui est le coupable : php ou debian ?

Bonjour,

J'ai fait executé par php le shell suivant :

Code:

---

1 2 3 4

<?php $adresse_mac = $_REQUEST['adresse_mac']; system('etherwake -i eth0 '.$adresse_mac ); ?>

---

Sa ne fonctionne pas, la commande est bonne, j'ai testé la même commande par print et copier coller vers un shell debian, la machine se réveille bien

J'ai testé depuis php ceci :

Code:

---

1 2	$file=$_REQUEST['file']; system ('touch '.$file);

---

sa fonctionne très bien..

Je ne comprend pas pourquoi il ne veut pas executer etherwake ??
j'ai cru qu'il s'agissait d'un problème de droit ..
Mais j'ai mis www-data avec les droits root et c'est identique
sa ne fonctionne pas mieux , j'ai essayé shell_exec , exec de php ect..
IDEM

Merci pour votre aide.

Je suppose que touch, étant une commande système de base, il n'y a aucun problème quant à l'exécution. Cela peut-être la cause de ton soucis.
As-tu essayé de mettre le chemin absolu de ton binaire etherwake?

Pour connaître sa localisation:

Code:

---

whereis etherwake

---

Donc tu auras quelque chose du genre:

Code:

---

1 2 3 4

<?php $adresse_mac = $_REQUEST['adresse_mac']; system('/usr/sbin/etherwake -i eth0 '.$adresse_mac ); ?>

---

Si etherwake est situé dans /usr/sbin.

Hélas , oui j'ai mis le path du binaire..
J'en avais tiré la même conclusion que toi , j'ai l'impression qu'il ne sait pas executé d'autre binaire que ceux du systeme debian..

Que donnes:
ls -all etherwake

sa donne cela :

debian#: ls -all /usr/sbin/etherwake

- rwxr - xr - x 1 root root 11020 jun 19 2007 /usr/sbin/etherwake

, Comme je disait , j'avais deja mis www-data en gid 0 , dans le meme groupe que root
c'est idem

Un test comme ça:
Peux-tu essayer de positionner le bit SETUID sur le binaire etherwake?

En root tape:

Code:

---

chmod 4755 /usr/sbin/etherwake

---

Cela te permettra d'exécuter etherwake avec les droits de l'user root.

Bien joué !!!

Ça marche !!

Donc un programme doit avoir le bit SUID pour être lancé en tant qu'utilisateur ?

Citation:

---

Donc un programme doit avoir le bit SUID pour être lancé en tant qu'utilisateur ?

---

Non, pas nécessairement, cela dépend.

Pour qu'un utilisateur lambda puisse exécuter un binaire appartenant à root avec les droits de root (comme les commandes passwd ou mount par ex), il faut positionner soit le bit SETUID, soit le bit SETGID.

Sinon le binaire sera exécuté mais avec les droits de l'utilisateur, d'où des éventuels soucis de non fonctionnement.
Par ex, pour terminer un processus, on utilise la commande kill.
Un utilisateur ne peut "killer" que les processus qui lui appartiennent (et heureusement).
Par contre, si l'on positionne le bit SETUID sur le binaire kill, un utilisateur lambda pourra tuer les processus appartenant à root.

Attention cependant à ne pas en coller de partout :aie:

Il me semble qu'utiliser sudo serait plus judicieux. Comme ça pas tous les utilisateurs peuvent lancer etherwake.

Le plus judicieux, c'est d'arrèter de faire exécuter ce genre de commande par php. Parce qu'à moins d'être dans un intranet de 5 personnes de confiance, il risque de se faire méchamment hacker ton serveur web. Les droits de root directement dans un php, c'est quand même un peu la fête du hacker.

Disons que 'etherwake' c'est plutôt dans un intranet d'une entreprise. De plus les droits root ne sont pas donnés au serveur Apache.
Et pour faire de l'administration réseau depuis une interface web, il faudra bien commencer à exécuter des commandes plus sensibles.
Finalement, en suivant ce raisonnement, des outils d'administration comme SWAT ou Webmin ne devrait jamais être utilisé en entreprise ?

Pour un intranet, ca peut rouler. Mais d'une manière générale, donner les droits suid sur un programme exécuté via php, c'est courir au carton. Ca fait partir des règles classiques de sécurité. Après, bien sur, il y a des évaluDès qu'on fait passer des paramêtresations à faire sur le risque. Un intranet d'entreprise n'est effectivement pas une jungle, dans la majorité des cas.

Quand à webmin, les méthodes mises en place pour assurer la sécurité sont tout de même globalement évaluées par la communauté d'utilisateurs .

C'est pourquoi j'ai recommandé sudo au lieu de setuid.