philippe69 Posté 27 Février 2008 Posté 27 Février 2008 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
Dan Posté 27 Février 2008 Posté 27 Février 2008 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.
destroyedlolo Posté 27 Février 2008 Posté 27 Février 2008 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.
pluriels Posté 27 Février 2008 Posté 27 Février 2008 il vaut peut-être mieux garder les warning et chercher à les résoudre plutôt que rajouter @ ...
Dan Posté 27 Février 2008 Posté 27 Février 2008 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
philippe69 Posté 27 Février 2008 Auteur Posté 27 Février 2008 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é.
Kioob Posté 28 Février 2008 Posté 28 Février 2008 (modifié) 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. Modifié 28 Février 2008 par Kioob
Anonymus Posté 28 Février 2008 Posté 28 Février 2008 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 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
Daxey Posté 28 Février 2008 Posté 28 Février 2008 (modifié) 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é 28 Février 2008 par Daxey
Dan Posté 28 Février 2008 Posté 28 Février 2008 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. 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 !
Kioob Posté 29 Février 2008 Posté 29 Février 2008 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.
Daxey Posté 29 Février 2008 Posté 29 Février 2008 mais en fait je ne sais pas ce que tu veux faire mais il y a sûrement une autre solution
Dan Posté 29 Février 2008 Posté 29 Février 2008 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é.
destroyedlolo Posté 29 Février 2008 Posté 29 Février 2008 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
Kioob Posté 29 Février 2008 Posté 29 Février 2008 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).
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant