Forum d'entraide PHPFrance

Bonjour,

J'ai un soucis avec un script qui marche parfaitement en local ainsi que chez free.fr mais pas chez mon hébergeur mavenhosting.

C'est très bête... Pour ouvrir un fichier avec ce code :
Et j'ai une erreur relative aux droits :

Warning: fopen(../rss.xml) [function.fopen]: failed to open stream: Permission denied in /home/**/public_html/**/rss.php on line 58

J'ai besoin de mettre le droit "w" aux autres sur mon fichier rss.xml... Ce qui signifie si je ne me trompe pas que Apache n'est pas considéré comme propriétaire ou groupe propriétaire des scripts.

D'ailleurs ce code :
Me renvoie "nobody".

Bon pourquoi ne pas mettre "w" aux others, et bien je me fait régulièrement hacker le contenu des mes fichiers xml en faisant cela.

Je tente donc ceci avant l'ouverture :
Mais j'obtient -1 , un echec donc... Normal Apache n'a sûrement pas les droits.

Voila donc le problème, j'aimerais pouvoir via du code php changer les droits de mes fichiers xml à la volée lors de l'éxécution du script.

Hélas à mon grand désespoir je ne voit pas comment faire... Pourriez-vous me dire si c'est possible, ou me donner une méthode permettant d'écrire dans mes fichiers sans laisser le droit "w" aux "others" en permanence ?

Merci de votre aide.

Tu dois donner les droits d'écriture via FTP pour "others" puisque "nobody" n'a pas les droits d'écriture et donc tu ne peux te les donner toi-même via un script PHP.

Mon avis est qu'il faudra que tu contactes ton hébergeur et que tu leur demandes d'activer PHPSuExec. Je suis certain qu'ils roulent sous cPanel et qu'ils peuvent l'activer facilement. Cependant à savoir s'ils vont le faire, j'en doute.

Choix possibles si tu ne peux avoir PHPSuExec:

1) Il faut donner les droits d'écriture via FTP au groupe "others" pour que "nobody" puisse y accéder.
2) Ou t'assurer de créer les fichiers/répertoires via un script PHP afin d'avoir les bons propriétaires dès le départ (nobody)

Point négatif à tout ça: Tout le monde peut écrire dans tes fichiers.

Merci pour ta réponse, j'ai fait comme tu m'a dit, j'ai créé les fichier avec un script php pour qu'il soit propriétaire de nobody. J'ai ensuite pu remetre les droit rw-r--r-- sur les fichiers.

Le scritp peut donc y accéder correctement.

Point négatif à tout ça: Tout le monde peut écrire dans tes fichiers.

Tu pourrais m'expliquer comment ? Un autre utilisateur de mon mutualisé pourrait y accéder via l'utilisateur nobdy (apache) mais de l'extérieur cela est-il possible ?

Merci ^^

Un autre utilisateur de mon mutualisé pourrait y accéder via l'utilisateur nobdy (apache)

De toute façon, tous les users de l'hébergement auront les mêmes droits que toi, quelqu'ils soient, vu que apache a les mêmes droits pour tout le monde. Les droits d'accès aux fichiers sont alors gérés par php (je pense notament à la directive open_dir. Donc si l'hébergement est bien configuré, il ne devrait pas y avoir d'accès à tes fichiers pour les autres utilisateurs…

mais de l'extérieur cela est-il possible ?

Clairement non

Merci pour votre aide précieuse encore une fois ^^

Si mes souvenirs sont bons, open_basedir n'est pas activés par défaut sous cPanel.

De plus, puisque les fonctions exec() semblent toujours actifs, un client pourrait démarrer un script Perl et bypasser la restriction open_basedir de PHP.

Si mes souvenirs sont bons, open_basedir n'est pas activés par défaut sous cPanel.

C'est un tort je pense

Dans tous les cas, c'est tout de même à l'hébergeur d'assurer à son client la sécurité totale vis à vis des autres utilisateurs, et s'il y a une faille de sécurité, c'est à dire des gens qui peuvent accéder à tes fichiers aussi bien que toi, c'est à lui qu'il faut se plaindre surtout…

Si mes souvenirs sont bons, open_basedir n'est pas activés par défaut sous cPanel.

De plus, puisque les fonctions exec() semblent toujours actifs, un client pourrait démarrer un script Perl et bypasser la restriction open_basedir de PHP.

Exact. Plus inquiétant même: la protection open_basedir a toujours été perméable. Le talon d'Achille de PHP:
http://www.securityfocus.com/bid/11557/exploit

Même pas besoin d'activer exec() et sa famille pour passer au travers. Un simple curl() suffit

Si mes souvenirs sont bons, open_basedir n'est pas activés par défaut sous cPanel.

C'est un tort je pense

Dans tous les cas, c'est tout de même à l'hébergeur d'assurer à son client la sécurité totale vis à vis des autres utilisateurs, et s'il y a une faille de sécurité, c'est à dire des gens qui peuvent accéder à tes fichiers aussi bien que toi, c'est à lui qu'il faut se plaindre surtout…

Une personne qui désire sérieusement s'inverstir dans l'hébergement aura fait le tour des fonctionnalités de cPanel et aura activé cette directive. J'en suis très conscient.

Si tu savais la quantité de personnes pour qui je dois offrir du support et qui ne connaisse rien à cPanel ou la gestion de serveurs... Il est trop facile de s'improviser hébergeur pour arrondir les fins de mois...

Ma triste spécialité au niveau du support est l'investigation lorsqu'il y a des serveurs hackés par des scripts PHP insécures...

Même pas besoin d'activer exec() et sa famille pour passer au travers. Un simple curl() suffit

L'extension curl n'est pas activée par défaut sous cPanel. Seuls les utilisateurs "avancés" demandent son activation ou savent comment l'activer via "Apache Update". Si l'extension curl est activée, la probabilité que cet utilisateur ne soit pas au courant des risques de sécurité d'include+GET est fortement réduite.

De plus, je ne connais pas de cas concrets où une variable GET serait utilisée directement dans la fonction curl_init(). Il faut donc avoir déjà uploadé un script malicieux ou être propriétaire d'un compte cPanel sur le serveur pour exploiter cette faille.

Dans le premier cas, une faille d'include a certainement été utilisée afin d'uploader un phpshell. Le populaire phpshell r57.txt utilise justement cette faille. c99.txt n'utilise pas cette faille et dépend des fonctions exec.