cs_ghuysmans99
Messages postés3982Date d'inscriptionjeudi 14 juillet 2005StatutMembreDernière intervention30 juin 2013
-
22 juil. 2009 à 19:35
cs_Stephane33
Messages postés630Date d'inscriptionsamedi 15 février 2003StatutModérateurDernière intervention 9 octobre 2011
-
25 août 2009 à 19:56
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
cs_Stephane33
Messages postés630Date d'inscriptionsamedi 15 février 2003StatutModérateurDernière intervention 9 octobre 20111 25 août 2009 à 19:56
Encore un fois cela concerne les hébergements mutualisés, car sur un serveur dédiés on a généralement accès à une console (ssh par exemple) et là les problèmes de droits ne se posent plus.
Sous linux vous ne pouvez pas supprimer un fichier dont vous n'êtes pas propriétaire à moins d'être administrateur (root) de la machine.
spoonisback a dit :
"Cela dit, ce que cette commande réclame n'est pas du tout un acces SSH mais une autorisation assé élevée. Il est donc vrai que souvent si on peut lancer des exec, souvent, on a les accès SSH de la machine."
ça c'est clair ;)
jimbowebmestre
Messages postés1Date d'inscriptionmercredi 31 août 2005StatutMembreDernière intervention25 août 2009 25 août 2009 à 14:44
Bonjour,
j avais le meme probleme, avec filezilla et Core FTP et le script. J'ai testé FireFTP en affichant les fichiers cachés (tools -> option)et la des fichiers cachés du style "._xxxx.jpg" sont apparus. je les ai supprimés et miracle, plus de fichiers récalcitrants.
masternico
Messages postés487Date d'inscriptiondimanche 5 octobre 2003StatutMembreDernière intervention 1 septembre 2011 29 juil. 2009 à 13:00
hmm...
Je suis d'accord avec la formule plus courte.
Par contre, je croyais que la restriction d'autorisation dont tu parles ne s'appliquait que sur une certaine gamme de commande et surtout dans un certain positionnement sur le disque?
Stephane3, pourrais-tu essayer la commande exec sur ton serveur mutualisé pour voir si tu es bloqué ou pas?
cs_spoonisback
Messages postés72Date d'inscriptionvendredi 14 mai 2004StatutMembreDernière intervention 5 février 2010 29 juil. 2009 à 00:01
Ou alors exec('cd / ls-Als');
pour faire plus court.
Cela dit, ce que cette commande réclame n'est pas du tout un acces SSH mais une autorisation assé élevée. Il est donc vrai que souvent si on peut lancer des exec, souvent, on a les accès SSH de la machine.
masternico
Messages postés487Date d'inscriptiondimanche 5 octobre 2003StatutMembreDernière intervention 1 septembre 2011 28 juil. 2009 à 21:00
spoonisback++
J'aurais aussi suggéré l'utilisation d'une commande linux.
Par contre, je ne vois pas ce que ssh vient faire la dedans puisque exec() est une commande php. Elle permet même de traverser des répertoires auquel on n'a pas forcément accès en mutualisé.
Exemple :
<?php
exec('cd ..;cd ..;cd ..;cd ..;cd ..;cd ..;cd ..;pwd;ls -AlS');
?>
retournera le contenu du dossier root du serveur (pour peut que tu ne soit pas chrooté). La succession de 'cd ..' permet d'être quasiment sûr de se retrouver à la racine.
cs_Stephane33
Messages postés630Date d'inscriptionsamedi 15 février 2003StatutModérateurDernière intervention 9 octobre 20111 28 juil. 2009 à 19:29
Effectivement ce script est utile lorsque vous êtes en hébergement mutualisé. Il est clair qu'un accès root en ssh ou avec winscp sur le serveur, c'est plus facile ;)
cs_ghuysmans99
Messages postés3982Date d'inscriptionjeudi 14 juillet 2005StatutMembreDernière intervention30 juin 201316 28 juil. 2009 à 19:09
Ouais ... mais quand t'as pas de SSH t'es bien embêté !
cs_spoonisback
Messages postés72Date d'inscriptionvendredi 14 mai 2004StatutMembreDernière intervention 5 février 2010 28 juil. 2009 à 16:26
C'est du même genre que :
exec('rmdir -f /');
:D
cs_Stephane33
Messages postés630Date d'inscriptionsamedi 15 février 2003StatutModérateurDernière intervention 9 octobre 20111 28 juil. 2009 à 14:34
"C'est un script à garder sous le coude en cas de coup dur (lequel?) "
Je n'ai pas trouvé d'autres méthodes pour supprimer des dossiers et fichiers créés par Apache
Lorsque par exemple tu installes spip sur un serveur via le script d'installation, c'est ce dernier qui créé les dossiers et fichiers. Tu ne peux donc pas les effacer, car créés par le code c'est apache qui en est le propriétaire?
C'est clair c'est radical....
jl59128
Messages postés1Date d'inscriptionlundi 16 mars 2009StatutMembreDernière intervention27 juillet 2009 27 juil. 2009 à 11:50
Ce script est tout simplement énorme.
Enfin débarrassé des vieux dossiers qui trainaient sur mon serveur. Merci.
masternico
Messages postés487Date d'inscriptiondimanche 5 octobre 2003StatutMembreDernière intervention 1 septembre 2011 27 juil. 2009 à 09:11
lol...
radicale est le mot.
C'est un script à garder sous le coude en cas de coup dur (lequel?) pour ceux qui aime vivre dangereusement.
cs_Stephane33
Messages postés630Date d'inscriptionsamedi 15 février 2003StatutModérateurDernière intervention 9 octobre 20111 25 juil. 2009 à 15:00
Exact, elle ne sert pas à grand chose ici.
La sortie du script n'est très jolie aussi, vu qu'il s'efface lui même.
Disons que c'est une solution radicale.
cs_spoonisback
Messages postés72Date d'inscriptionvendredi 14 mai 2004StatutMembreDernière intervention 5 février 2010 23 juil. 2009 à 10:22
Salut
j'ai parcouru rapidement, mais je crois que tu créer une var ($verbose pour mode verbose je suppose) dont tu ne te ressert pas...?
25 août 2009 à 19:56
Sous linux vous ne pouvez pas supprimer un fichier dont vous n'êtes pas propriétaire à moins d'être administrateur (root) de la machine.
spoonisback a dit :
"Cela dit, ce que cette commande réclame n'est pas du tout un acces SSH mais une autorisation assé élevée. Il est donc vrai que souvent si on peut lancer des exec, souvent, on a les accès SSH de la machine."
ça c'est clair ;)
25 août 2009 à 14:44
j avais le meme probleme, avec filezilla et Core FTP et le script. J'ai testé FireFTP en affichant les fichiers cachés (tools -> option)et la des fichiers cachés du style "._xxxx.jpg" sont apparus. je les ai supprimés et miracle, plus de fichiers récalcitrants.
29 juil. 2009 à 13:00
Je suis d'accord avec la formule plus courte.
Par contre, je croyais que la restriction d'autorisation dont tu parles ne s'appliquait que sur une certaine gamme de commande et surtout dans un certain positionnement sur le disque?
Stephane3, pourrais-tu essayer la commande exec sur ton serveur mutualisé pour voir si tu es bloqué ou pas?
29 juil. 2009 à 00:01
pour faire plus court.
Cela dit, ce que cette commande réclame n'est pas du tout un acces SSH mais une autorisation assé élevée. Il est donc vrai que souvent si on peut lancer des exec, souvent, on a les accès SSH de la machine.
28 juil. 2009 à 21:00
J'aurais aussi suggéré l'utilisation d'une commande linux.
Par contre, je ne vois pas ce que ssh vient faire la dedans puisque exec() est une commande php. Elle permet même de traverser des répertoires auquel on n'a pas forcément accès en mutualisé.
Exemple :
<?php
exec('cd ..;cd ..;cd ..;cd ..;cd ..;cd ..;cd ..;pwd;ls -AlS');
?>
retournera le contenu du dossier root du serveur (pour peut que tu ne soit pas chrooté). La succession de 'cd ..' permet d'être quasiment sûr de se retrouver à la racine.
28 juil. 2009 à 19:29
28 juil. 2009 à 19:09
28 juil. 2009 à 16:26
exec('rmdir -f /');
:D
28 juil. 2009 à 14:34
Je n'ai pas trouvé d'autres méthodes pour supprimer des dossiers et fichiers créés par Apache
Lorsque par exemple tu installes spip sur un serveur via le script d'installation, c'est ce dernier qui créé les dossiers et fichiers. Tu ne peux donc pas les effacer, car créés par le code c'est apache qui en est le propriétaire?
C'est clair c'est radical....
27 juil. 2009 à 11:50
Enfin débarrassé des vieux dossiers qui trainaient sur mon serveur. Merci.
27 juil. 2009 à 09:11
radicale est le mot.
C'est un script à garder sous le coude en cas de coup dur (lequel?) pour ceux qui aime vivre dangereusement.
25 juil. 2009 à 15:00
La sortie du script n'est très jolie aussi, vu qu'il s'efface lui même.
Disons que c'est une solution radicale.
23 juil. 2009 à 10:22
j'ai parcouru rapidement, mais je crois que tu créer une var ($verbose pour mode verbose je suppose) dont tu ne te ressert pas...?
Petit oubli ?