Aller au contenu

Warning sur file_exist


philippe69

Sujets conseillés

Bonjour à tous,

Mes scripts PHP sont sur une machine Linux.

Quand j'appelle :

file_exists( '/usr/bin/gzip')

j'ai le warning suivant :

Warning: file_exists() [function.file-exists]: open_basedir restriction in effect. File(/usr/bin/gzip) is not within the allowed path(s): (/home/heitz/:/tmp:/usr/local/lib/php/) in /home/heitz/domains/heitz-music.com/public_html/parametrage/backup.php on line 428

Je ne sais pas quoi modifier pour éviter ce warning.

Comment faire pour que File(/usr/bin/gzip) soit dans le path autorisé ?

Merci de votre aide

Cordialement

Philippe69

Lien vers le commentaire
Partager sur d’autres sites

Il te suffit de supprimer le open_basedir dans le panneau d'amdim de DirectAdmin

C'est tout en bas, "Configuration du safe mode de Php"

Si tu es seul sur ton serveur, je te suggère de le désactiver par défaut.

Lien vers le commentaire
Partager sur d’autres sites

Je n'utilise pas se genre de restriction mais je pense que la doc de PHP, section securite, te donnera toutes les informations qui te sont necessaires.

Pour evite par contre le warning, met simplement un '@' devant l'appel de la fonction.

Lien vers le commentaire
Partager sur d’autres sites

il vaut peut-être mieux garder les warning et chercher à les résoudre plutôt que rajouter @ ...

C'est pour cette raison que je lui ai donné la solution :)

Dan

Lien vers le commentaire
Partager sur d’autres sites

Ca fonctionne avec la solution de Dan. Merci.

N'aurais-je pas intérêt à modifier le open_basedir de php.ini afin d'y ajouter /usr/bin/gzip et laisser actif par défaut open_basedir ?

Cela n'ouvrirai pas de faille de sécurité.

Lien vers le commentaire
Partager sur d’autres sites

Dans le cas warnings déclenchées par l'open_basedir, je pense que la solution de l'arobase reste la plus propre malgré tout (sic...).

file_exists() est déjà une fonction de test pour éviter ce genre d'erreurs non ? Pour moi c'est une idiotie d'avoir ajouté ce warning sur toutes les fonctions de test (is_dir, is_file, etc). On a à ma connaissance aucun moyen simple de faire un test "open_basedir" sans déclencher ces erreurs.

Et désactiver une sécurité dès qu'on rencontre ce genre de petit "tracas" me semble bien imprudent : dans l'élan on vire le safe mode, l'openbasedir, on laisse PHP en module et on fait tourner Apache en root , comme ça on évitera aussi de se prendre la tête avec les droits d'accès. :D

Modifié par Kioob
Lien vers le commentaire
Partager sur d’autres sites

L'autre solution est de vérifier une bonne fois pour toutes si : file_exists( '/usr/bin/gzip')

et si oui, considérer que le test est bon :D

Et éventuellement, prévoir un script en cas de déménagement du programme : install.php, avec le file_exists dedans.

Ce genre de fichier ( '/usr/bin/gzip') ne bouge pas tous les jours.

Faire un test à chaque install devrait être suffisant plutot qu'un test à chaque ouverture de page ;)

Lien vers le commentaire
Partager sur d’autres sites

tu peux rajouter dans le vhost les dossiers auxquels tu veux avoir accès

attention tout de même à la sécurité

exemple :

php_admin_value open_basedir "/home/user/htdocs:/usr/bin/gzip"

Modifié par Daxey
Lien vers le commentaire
Partager sur d’autres sites

Et désactiver une sécurité dès qu'on rencontre ce genre de petit "tracas" me semble bien imprudent : dans l'élan on vire le safe mode, l'openbasedir, on laisse PHP en module et on fait tourner Apache en root , comme ça on évitera aussi de se prendre la tête avec les droits d'accès. :D

Philippe est seul sur son serveur... et pas besoin de laisser tourner apache en "root" (ce qui serai une grosse connerie).

La sécurité sur un serveur qu'on ne partage pas n'a pas les mêmes contraintes. Et dans son cas le fait de supprimer l'open_basedir ne change strictement rien.

Faut arrêter d'être parano !

Lien vers le commentaire
Partager sur d’autres sites

Et bien pour moi faire sauter une sécurité, même quand on est "seul" sur le serveur cela reste risqué : pour peu qu'il utilise phpmyadmin, phpbb, roundcube (ou autre script externe du genre), en cas de faille dans l'un d'eux les autres applis ainsi que le site lui même sera inutilement exposé.

Donc à moins d'utiliser un serveur dédié pour une seule application, il y a toujours un risque. Il s'agit quand même de faire tourner toutes les applications sous le même utilisateur... je suppose que ça ne te viendrais pas à l'idée pour les applications "non php" alors qu'elles sont beaucoup moins exposées que les applications PHP.

Appel ça de la parano si tu veux, pour moi il s'agit juste de sécurité de base.

Lien vers le commentaire
Partager sur d’autres sites

Appel ça de la parano si tu veux, pour moi il s'agit juste de sécurité de base.

Comment explique-tu alors que chez de nombreux hébergeurs mutualisés, le open_basedir ou le safe_mode ne soient pas activés ?

Sont-t-ils tous inconscients ? J'ai quelques doutes.

De même pour Php, il n'est pas actif par défaut, alors que sur Php5.2 le allow_url_include est mis à off... justement pour une question de sécurité.

Lien vers le commentaire
Partager sur d’autres sites

Le safe mode a surtout ete cree pour les hebergeurs surtout mutualises ou les membres peuvent ecrire eux meme leur code PHP.

De mon cote, comme je suis tout seul sur mon serveur, je prefere blinde cote droits unix plutot que de devoir batailler avec ce genre de chose. Le fait que je ne rende pas public non plus d'autres applications que celles que j'ai fait aide aussi :whistling:

Lien vers le commentaire
Partager sur d’autres sites

Comment explique-tu alors que chez de nombreux hébergeurs mutualisés, le open_basedir ou le safe_mode ne soient pas activés ?

Sont-t-ils tous inconscients ? J'ai quelques doutes.

De même pour Php, il n'est pas actif par défaut, alors que sur Php5.2 le allow_url_include est mis à off... justement pour une question de sécurité.

Tout simplement parce que les hébergeurs mutualisés font rarement tourner PHP en module ; et chaque client a son propre compte unix.

Si ce n'était pas le cas, chaque client (ou site de client se faisant hacker...) pourrait sans contrainte aucune lire les fichiers "db.config.php" de ses voisins...

Quant au fichier de configuration "par défaut" de PHP, il y est généralement écrit dès le début qu'il ne s'agit absolument pas d'un fichier utilisable en production

(sinon on aurrait display_errors à off, log_errors à on et error_reporting à E_ALL).

Lien vers le commentaire
Partager sur d’autres sites

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...