ambroisemaupate
26/05/2014, 18h32
Envoyé par Gaston_Phone
Mod_php et chmod à 0777 et 0666
Envoyé par Gaston_Phone
Gaston_Phone
26/05/2014, 18h23
777 --> Porte grande ouverte au piratage.
ambroisemaupate
26/05/2014, 16h54
Merci @gaboul49 pour ta réponse.
La méthode me parait logique dans le cas d’un site n’utilisant pas un CMS, on limite l’écriture aux seuls scripts concernés. Mais lorsque la racine du site doit être inscriptible, cela devient compliqué à gérer (quand le CMS se met à jour tout seul).
Le problème est que si je mets du 700 et 600 sur les fichiers, je ne pourrai plus les manipuler en FTP. (Par exemple, le client veut uploader un fichier trop volumineux directement en FTP, au lieu d’utiliser le formulaire HTTP, le dossier doit être en 777 (ou au moins 775) pour accepter Apache et user_bidule).
Les fichiers créés en FTP ont les propriétaires/groupe user_bidule:users. D’où la réponse du support évoquant les droits en 777 et 666.
Par exemple, j’utilise un script qui retaille les images clients à la volée et qui les stocke en cache pour ne pas à les générer à chaque requête. Je me retrouve avec des fichiers apache:apache avec le mod 0644. Du coup je ne peux plus les manipuler en FTP.
Idem pour le fichier de configuration du CMS qui est généré la première fois par PHP. Ça m'embête vraiment qu’il soit lisible par Apache en sachant que les identifiants MySQL sont inscrits en clair dedans.
La seule solution jusqu'à maintenant est de faire un umask(0) au début de chaque script générant des fichiers. Ça me parait pas très académique.
Bon après j'en fait peut être trop…
La méthode me parait logique dans le cas d’un site n’utilisant pas un CMS, on limite l’écriture aux seuls scripts concernés. Mais lorsque la racine du site doit être inscriptible, cela devient compliqué à gérer (quand le CMS se met à jour tout seul).
Le problème est que si je mets du 700 et 600 sur les fichiers, je ne pourrai plus les manipuler en FTP. (Par exemple, le client veut uploader un fichier trop volumineux directement en FTP, au lieu d’utiliser le formulaire HTTP, le dossier doit être en 777 (ou au moins 775) pour accepter Apache et user_bidule).
Les fichiers créés en FTP ont les propriétaires/groupe user_bidule:users. D’où la réponse du support évoquant les droits en 777 et 666.
Par exemple, j’utilise un script qui retaille les images clients à la volée et qui les stocke en cache pour ne pas à les générer à chaque requête. Je me retrouve avec des fichiers apache:apache avec le mod 0644. Du coup je ne peux plus les manipuler en FTP.
Idem pour le fichier de configuration du CMS qui est généré la première fois par PHP. Ça m'embête vraiment qu’il soit lisible par Apache en sachant que les identifiants MySQL sont inscrits en clair dedans.
La seule solution jusqu'à maintenant est de faire un umask(0) au début de chaque script générant des fichiers. Ça me parait pas très académique.
Bon après j'en fait peut être trop…
gaboul49
26/05/2014, 16h22
Sauf si tu obtiens l'autorisation d'héberger ton appli sur un autre serveur tu dois te soumettre à l'admin sys.
Sa méthode parait néanmoins logique, les fichiers qui peuvent être écrit doivent avoir les droits en écriture.
Cependant je te recommande de mettre les dossier en 700 et les fichiers en 600 avec comme user/group apache:apache. C'est déjà plus restrictif.
L'accès en ssh n'y changera rien.
Est-ce que j'ai loupé une partie ton explication ?
Sa méthode parait néanmoins logique, les fichiers qui peuvent être écrit doivent avoir les droits en écriture.
Cependant je te recommande de mettre les dossier en 700 et les fichiers en 600 avec comme user/group apache:apache. C'est déjà plus restrictif.
L'accès en ssh n'y changera rien.
Est-ce que j'ai loupé une partie ton explication ?
ambroisemaupate
26/05/2014, 13h59
Bonjour,
Je viens vous poser une petite question technique. J’ai l’habitude d’installer des VPS Cloud pour le compte de nos clients en utilisant notre propre CMS. Je prends à chaque fois soin d’installer un environnement cloisonné pour chaque virtual hosts. En utilisant Nginx + PHP-FPM ou Apache - PHP-FPM ou au début j'utilisais le MPM-ITK d’Apache (c'était la solution de facilité ).
Je dois aujourd’hui installer notre solution sur le serveur d’une institution qui déjà infogéré par une société inconnue au bataillon.
Je me retrouve avec un User FTP personnel (sans SSH, ni Git) et un PHP tournant avec les droits Apache.
Ayant besoin de pouvoir modifier des fichiers autant "à la main" que par le biais de PHP, je contacte le support en leur demandant de modifier le mode d’exécution de PHP. Ils me répondent qu’Apache tourne avec mod_php et que je dois mettre tous les dossiers en 777 et fichiers en 666 là où le CMS a besoin de manipuler des fichiers.
Alors ma question est : est-ce bien propre ?? Et quelles sont les raisons de cet hébergeur à laisser une install par défaut alors qu’OVH ou les autres proposent par défaut un fast-CGI pour cloisonner leurs utilisateurs.
Le point noir étant que notre CMS peut se mettre à jour automatiquement en téléchargeant ses dernières sources, et là si la majeur partie des fichiers de mon FTP se retrouvent en Apache:Apache, je suis bien embêté !
Je me bats depuis quelques mois avec des services informatiques de ce genre qui ne veulent ni nous fournir un accès SSH ou avec des process PHP tournant avec les bons droits. Avez-vous les mêmes expériences ? Et si oui comment gérez-vous ces problèmes ?
Merci d’avances pour vos avis et vos suggestions !
Ambroise
Je viens vous poser une petite question technique. J’ai l’habitude d’installer des VPS Cloud pour le compte de nos clients en utilisant notre propre CMS. Je prends à chaque fois soin d’installer un environnement cloisonné pour chaque virtual hosts. En utilisant Nginx + PHP-FPM ou Apache - PHP-FPM ou au début j'utilisais le MPM-ITK d’Apache (c'était la solution de facilité ).
Je dois aujourd’hui installer notre solution sur le serveur d’une institution qui déjà infogéré par une société inconnue au bataillon.
Je me retrouve avec un User FTP personnel (sans SSH, ni Git) et un PHP tournant avec les droits Apache.
Ayant besoin de pouvoir modifier des fichiers autant "à la main" que par le biais de PHP, je contacte le support en leur demandant de modifier le mode d’exécution de PHP. Ils me répondent qu’Apache tourne avec mod_php et que je dois mettre tous les dossiers en 777 et fichiers en 666 là où le CMS a besoin de manipuler des fichiers.
Alors ma question est : est-ce bien propre ?? Et quelles sont les raisons de cet hébergeur à laisser une install par défaut alors qu’OVH ou les autres proposent par défaut un fast-CGI pour cloisonner leurs utilisateurs.
Le point noir étant que notre CMS peut se mettre à jour automatiquement en téléchargeant ses dernières sources, et là si la majeur partie des fichiers de mon FTP se retrouvent en Apache:Apache, je suis bien embêté !
Je me bats depuis quelques mois avec des services informatiques de ce genre qui ne veulent ni nous fournir un accès SSH ou avec des process PHP tournant avec les bons droits. Avez-vous les mêmes expériences ? Et si oui comment gérez-vous ces problèmes ?
Merci d’avances pour vos avis et vos suggestions !
Ambroise