Me revoila parti dans les truc tordus ...

Zecat · 12 Octobre 2010

Pour résoudre un pb je me pose une quetsiuon : est il possible (souhaitable) de faire executer sur un serveur web un petit bout C/C++ (ou plus generalement un executable compilé quel qu'il soit).

Je m'explique : je voudrais faire ecrire une bpoite noire "montrucenC" qui va faire un travail spécifique (en entrée il a un truc , en sortie il a fait son travail). Et ensuite je voudrais pouvoir dans une page php ecrire un truc du style :

<?php

.
.
.
je mets un truc sur le disque du serveur

j'execute montrucenC

je vais lire sur le disque du serveur le resultat du ttaf en c ..
?>

Est ce que y a des instructions en php pour faire cela (style exec($chemin)

Hum hum je sens que ca va encore etre un truc pour mon jacques préféré :mrgreen:

Aaarrrgggh · 12 Octobre 2010

Oui tu peux l'utiliser. Il y a aussi Syst je crois ou un truc dans le style. Mais ces fonctions sont désactivées sur les hébergements mutualisés il me semble pour raison de sécurité.

Zecat · 12 Octobre 2010

Aaarrrgggh a dit:
Mais ces fonctions sont désactivées sur les hébergements mutualisés il me semble pour raison de sécurité.

arfff

edit : j'avais ecris "exec" au pif ... ne sachant pas que cette commande existait en php :mrgreen:

Aaarrrgggh · 12 Octobre 2010

Si, il y a aussi passthru, shell_exec, et system.

jcaron · 12 Octobre 2010

La première question qui me vient à l'esprit c'est "pourquoi?". J'ai une petite idée des raisons possibles, mais je suis curieux

Sinon, effectivement, il y a plusieurs méthodes pour appeler un programme externe, sachant que tu n'es même pas forcément obligé d'utiliser des fichiers temporaires pour communiquer avec lui, tu peux passer des arguments, et tu peux communiquer via des pipes dans les deux sens. En plus de exec, system et passthru, il y a aussi popen, proc_open, et tous leurs copains.

Maintenant, il faut faire très, très attention: la plupart de ces commandes (toutes?) passent en fait la ligne de commande à un shell, qui peut interpréter toutes sortes de choses si elles ne sont pas correctement escapées. De la même façon, il faut aussi très fortement contrôler les chemins de fichiers passés, histoire qu'un attaquant ne puisse pas accéder à des fichiers auxquels il ne devrait pas à grands coups de ".." par exemple...

Jacques.

spout · 12 Octobre 2010

Aaarrrgggh a dit:
Si, il y a aussi passthru, shell_exec, et system.

Et il y a aussi le "backtick":

Code:

<?php
$output = `ls -al`;
echo "<pre>$output</pre>";
?>

http://php.net/manual/fr/language.operators.execution.php

Zecat · 12 Octobre 2010

jcaron a dit:
La première question qui me vient à l'esprit c'est "pourquoi?". J'ai une petite idée des raisons possibles, mais je suis curieux

La première raison est purement mecanique ; deporter en compilé un traitement qui frise régulièrement avec la limite des 30s en php ... alors que je sais pas experience que le meme traitement bien codé et compilé c'est un truc qui va se mesurer en millisecondes ...

Ensuite, tant qu'a explorer cette piste (je suis en pleine formation ne l'oublie pas), je vais essayer de voir dans quellemesure elle ne peut pas être plus ou moins généralisée et appliquée à tout traitement un peu long et stabilisé avec comme résultat attendu un gain en ressources consommées ...

And last but not least, rendre vraiment confidentielle une moulinette en pouvant lamettre a disposition d'autres webmaster sous forme de plug-in compilé.

Ben voui, je suis un pisseur de code depuis 30 ans, on se refait pas :mrgreen:

jcaron a dit:
Sinon, effectivement, il y a plusieurs méthodes pour appeler un programme externe, sachant que tu n'es même pas forcément obligé d'utiliser des fichiers temporaires pour communiquer avec lui, tu peux passer des arguments, et tu peux communiquer via des pipes dans les deux sens. En plus de exec, system et passthru, il y a aussi popen, proc_open, et tous leurs copains.

Maintenant, il faut faire très, très attention: la plupart de ces commandes (toutes?) passent en fait la ligne de commande à un shell, qui peut interpréter toutes sortes de choses si elles ne sont pas correctement escapées. De la même façon, il faut aussi très fortement contrôler les chemins de fichiers passés, histoire qu'un attaquant ne puisse pas accéder à des fichiers auxquels il ne devrait pas à grands coups de ".." par exemple...

Jacques.

Bon je vais creuser tout ca avec la prudence qui s'impose ...

tofm2 · 12 Octobre 2010

et ton truc en c, dans le répertoire CGI de ton serveur ?

Peut être le plus simple ?

Zecat · 12 Octobre 2010

C'ets quoi le repertoire CGI ? :roll:

Bon en tout cas, mon approche ne vous fait pas faire des grands sauts de cabri, donc j'en conclu que :

1 - c'est pas totalement hérétique
2 - d'autres le font déjà :wink:

milkiway · 13 Octobre 2010

Comme le dit jacques, les compétences impératives ici sont bien plus en sécurité et administration serveur qu'en programmation. Si tu es en mutualisé, oublies tout de suite.

Zecat · 13 Octobre 2010

oui oui vu le nombre de mises en garde sur les aspects securité, je vais y aller piano ... juste debroussailler pour comprendre comment faire pour le moment ... et de toute façon je n'ai que des mutus ... (ca serait peut etre l'occasion de me lancer dans mon premier dédié ...)

milkiway · 13 Octobre 2010

Alors si tu n'as que des mutus je doute très très fort que ce soit possible

Ils ne sont pas fous quand même!

Un conseil, avant de passer au dédié, prends toi un kimsufi de base pour te faire la main pendant quelques semaines/mois.
Je suis passé du mutu au dédié par obligation... je galère comme c'est pas possible.
Heureusement que notre ami Julia traine sur le forum et qu'il est très calé car dès que j'aurai fait le tour de mes souci, je le contacterai pour lui demander un peu d'infogérance : https://admin-serv.net/

Tiens d'ailleurs, pose lui la question.

Zecat · 13 Octobre 2010

T'inquiète, j'ai un peu de bouteille en dev et debroussaillages de tous types ... et quelques reflexés acquis au fil des ans pour pas tout péter :mrgreen: Je vais déjà debroussailler en localhost ...

D'aillerus depuis que je fais "du web", je touche du bois mais j'ai encore jamais eu a recharger une secu because "mais il a tout pété" :wink: La seule fois ou j'aurais eu besoin de recharger une secu, c'est pas moi qui les faisaient ... l'autre non plus d'ailleurs :mrgreen: (joke ...cf topic yag).

milkiway · 13 Octobre 2010

Hé bien je suis comme toi, j'ai même une machine Linux chez moi, et bien je galère...

tofm2 · 13 Octobre 2010

Zecat a dit:
C'ets quoi le repertoire CGI ?

Un repertoire configuré qui contient des executables quel qu'en soit le langage de programmation, ces executables pissent du html, interprété comme tel par le serveur
http://httpd.apache.org/docs/trunk/fr/howto/cgi.html
c'est ce qu'on utilisait avant php.

ricosound · 14 Octobre 2010

Zecat a dit:
C'ets quoi le repertoire CGI ? :roll:

Bon en tout cas, mon approche ne vous fait pas faire des grands sauts de cabri, donc j'en conclu que :

1 - c'est pas totalement hérétique
2 - d'autres le font déjà :wink:

Salut rro minet.

3 - d'autres y pensent sérieusement devant les piètres performances du couple php/sql.

Mais aussi "pisseur de code" au départ ! :mrgreen:

Bonne journée, Éric.

spout · 14 Octobre 2010

ricosound a dit:
3 - d'autres y pensent sérieusement devant les piètres performances du couple php/sql.

Il faut penser au couple PHP/MongoDB, et utiliser du cache d'opcode (APC).

Mais c'est vrai que pour de gros traitements, un programme en C ira tjs plus vite

Sur Facebook, ils utilisent HipHop PHP pour transformer du code PHP en C++.