Apache var/www modification de fichier.php
Fermé
Lux Fero
-
28 sept. 2010 à 23:30
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 2 oct. 2010 à 01:31
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 2 oct. 2010 à 01:31
A voir également:
- Var/www/html
- Editeur html - Télécharger - HTML
- Nbsp html ✓ - Forum Webmastering
- Espace en html - Astuces et Solutions
- Html download - Télécharger - HTML
- Br html ✓ - Forum Webmastering
3 réponses
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
29 sept. 2010 à 00:32
29 sept. 2010 à 00:32
Parce que ton utilisateur n'a pas les droits en écriture sur ces fichiers. Regarde les droits associés à /var/www :
A priori je pense que le propriétaire est root et le groupe www-data (reporte-moi le résultat de cette commande) et que les deux ont les droits en écriture sur ce répertoire. Il suffit d'ajouter ton utilisateur à ce groupe pour corriger le problème.
Plus de détails ici :
http://forum.ubuntu-fr.org/viewtopic.php?id=113562
Bonne chance
ls -l /var/www
A priori je pense que le propriétaire est root et le groupe www-data (reporte-moi le résultat de cette commande) et que les deux ont les droits en écriture sur ce répertoire. Il suffit d'ajouter ton utilisateur à ce groupe pour corriger le problème.
Plus de détails ici :
http://forum.ubuntu-fr.org/viewtopic.php?id=113562
Bonne chance
Utilisateur anonyme
Modifié par just1602 le 29/09/2010 à 00:37
Modifié par just1602 le 29/09/2010 à 00:37
Salut,
Tu ne peux pas modifier les fichier dans /var/www car à la base tu n'est pas le propriétaire du dossier.
Pour plus d'informations tu peux regarder cette page.
Pour ce qui est de te permettre de modifier les fichier je dirais qu'avec la commande chown ça devrait fonctionner. Donc :
Si une fois cette commande lancer et exécuté avec succès ça ne fonctionne pas.
Essai :
@++ :- )
Edit : Je ne tapes pas assez vite ,, shifted by mamiemando ;-P
Tu ne peux pas modifier les fichier dans /var/www car à la base tu n'est pas le propriétaire du dossier.
Pour plus d'informations tu peux regarder cette page.
Pour ce qui est de te permettre de modifier les fichier je dirais qu'avec la commande chown ça devrait fonctionner. Donc :
chown -R user:user /var/www
Si une fois cette commande lancer et exécuté avec succès ça ne fonctionne pas.
Essai :
chown -R user:user /var/www/*
@++ :- )
Edit : Je ne tapes pas assez vite ,, shifted by mamiemando ;-P
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
29 sept. 2010 à 00:44
29 sept. 2010 à 00:44
Ben ce qui me gêne c'est que là c'est un chown qui ne me paraît pas très jusitifé. Tous les utilisateurs qui doivent pouvoir modifier ces pages doivent simplement être membre de www-data. Même si ta solution marche, les droits que tu définis ne sont pas super.
+1 avec mamiemando...
On ne change pas les droit/propriétaire de /var/www/ ...
Au mieux, on crée un dossier dans ~/user/nom_du_dossier
On fait un : ln -s ~/user/nom_du_dossier /var/www/
On déplace le contenu de /var/www/ dans ~/user/nom_du_dossier
Ce qui permettra à l'utilisateur de pouvoir modifier les fichiers, les afficher dans le serveur WEB et ce sans avoir eu à retoucher au proprio/droit de /var/www
On ne change pas les droit/propriétaire de /var/www/ ...
Au mieux, on crée un dossier dans ~/user/nom_du_dossier
On fait un : ln -s ~/user/nom_du_dossier /var/www/
On déplace le contenu de /var/www/ dans ~/user/nom_du_dossier
Ce qui permettra à l'utilisateur de pouvoir modifier les fichiers, les afficher dans le serveur WEB et ce sans avoir eu à retoucher au proprio/droit de /var/www
lami20j
Messages postés
21331
Date d'inscription
jeudi 4 novembre 2004
Statut
Modérateur, Contributeur sécurité
Dernière intervention
30 octobre 2019
3 567
29 sept. 2010 à 11:51
29 sept. 2010 à 11:51
Salut,
A la limite pourquoi pas utiliser un editeur de texte avec la commande sudo?
A la limite pourquoi pas utiliser un editeur de texte avec la commande sudo?
sudo gedit /var/www/fichier.php&
je vous remercie les amis:
mais chown marche pas à tout les coups je pense voilà ce qu'il me donne:
aussi daccord pour le gedit mais je pense qu'il s'agit plus des droits d'access!
quand à mamiemando voila les droits d'accés sur var/www (j'ai seulement ceux du fichier "phpinfo.php" comme vous pouvez le constater il est a moi.
je me suis ajouter au groupe www-data:
et changer les droits du racine var/www:
et maintenant je peux créer et modifer les fichiers qui se trouvent dans var/www
à l'exception du index.php et phpmyadmin dans la même racine.
mais chown marche pas à tout les coups je pense voilà ce qu'il me donne:
login@login:~$ chown -R login /var/www chown: changement de propriétaire pour '/var/www/phpinfo.php~': Opération non permise chown: changement de propriétaire pour '/var/www/phpmyadmin': Opération non permise chown: changement de propriétaire pour '/var/www/index.html': Opération non permise
aussi daccord pour le gedit mais je pense qu'il s'agit plus des droits d'access!
quand à mamiemando voila les droits d'accés sur var/www (j'ai seulement ceux du fichier "phpinfo.php" comme vous pouvez le constater il est a moi.
ls -l /var/www total 12 -rw-r--r-- 1 root root 45 2010-06-29 22:29 index.html -rw-r--r-- 1 login root 96 2010-09-29 16:27 phpinfo.php -rw-r--r-- 1 login login 96 2010-09-29 16:27 phpinfo.php~ lrwxrwxrwx 1 root root 21 2010-06-29 22:38 phpmyadmin -> /usr/share/phpmyadmin
je me suis ajouter au groupe www-data:
sudo adduser login www-data
et changer les droits du racine var/www:
chmod g+w /var/www
et maintenant je peux créer et modifer les fichiers qui se trouvent dans var/www
à l'exception du index.php et phpmyadmin dans la même racine.
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
1 oct. 2010 à 11:02
1 oct. 2010 à 11:02
Bon stop je vois trop de trucs qui me piquent les yeux :)
Pour commencer pour lancer un éditeur texte graphique avec des droits root, il faut éviter sudo et préférer gksudo, cf les explications ici :
http://doc.ubuntu-fr.org/sudo#quand_doit-on_utiliser_sudogksudokdesudo
1) gksudo paramètre le dossier personnel (la variable d'environnement $HOME) pour l'application exécutée en mode privilégiée à /root plutôt qu'à /home/<identifiant> et copie le fichier .Xauthority dans un dossier temporaire. Ceci empêche que des fichiers du dossier personnel de l'utilisateur changent de propriétaire (et donc corrompent la session graphique en cours).
Pour le lien symbolique pourquoi pas a priori dans le cas particulier d'apache ça marche peut être, mais pas dans celui d'un serveur "jailé" comme par exemple proftpd. Le lien symbolique ferait remonter depuis /var/www via ../../home/mando/site (ou directement /home/mando/site ce qui revient de toute façon au même) et force à "sortir" de /var/www. Dans un serveur jailé ce ne serait pas possible.
Je pense que ce n'est d'ailleurs pas systématiquement possible en apache si on autorise pas le suivi des liens symbolique.
Seule solution, utiliser des "mount bind" :
https://forums.commentcamarche.net/forum/affich-1906184-lien-symbolique-intilisable-en-ftp
Ensuite il n'y a pas vraiment de raison de stocker le site dans un home à part dans un contexte "mono utilisateur" et encore. Tous les "documents" attachés à une application n'appartiennent pas spécialement à un utilisateur et c'est pourquoi le "home" de ces applications est bien dans /var/lib ou /var/www (cf apache, mysql, munin et bien d'autres).
Imaginons par exemple que l'utilisateur mando héberge les "pages" en question et qu'il décide brusquement de restreindre l'accès à son home. Et bien c'est dommage mais là avec lien symbolique on sera coincé (pas avec un mount bind qui est exécuté par root) mais conceptuellement ce dossier n'a rien à faire dans son home. Je rappelle au passage qu'un utilisateur peut dégager de son home un fichier qui ne lui appartient pas même s'il n'a pas les droits dessus (ben oui.. c'est son home :p).
Preuve :
Bref... laissons les pages à leur place et mettons simplement mando... dans www-data... comme c'est prévu à la base.
Bonne chance
Pour commencer pour lancer un éditeur texte graphique avec des droits root, il faut éviter sudo et préférer gksudo, cf les explications ici :
http://doc.ubuntu-fr.org/sudo#quand_doit-on_utiliser_sudogksudokdesudo
1) gksudo paramètre le dossier personnel (la variable d'environnement $HOME) pour l'application exécutée en mode privilégiée à /root plutôt qu'à /home/<identifiant> et copie le fichier .Xauthority dans un dossier temporaire. Ceci empêche que des fichiers du dossier personnel de l'utilisateur changent de propriétaire (et donc corrompent la session graphique en cours).
Pour le lien symbolique pourquoi pas a priori dans le cas particulier d'apache ça marche peut être, mais pas dans celui d'un serveur "jailé" comme par exemple proftpd. Le lien symbolique ferait remonter depuis /var/www via ../../home/mando/site (ou directement /home/mando/site ce qui revient de toute façon au même) et force à "sortir" de /var/www. Dans un serveur jailé ce ne serait pas possible.
Je pense que ce n'est d'ailleurs pas systématiquement possible en apache si on autorise pas le suivi des liens symbolique.
Seule solution, utiliser des "mount bind" :
https://forums.commentcamarche.net/forum/affich-1906184-lien-symbolique-intilisable-en-ftp
Ensuite il n'y a pas vraiment de raison de stocker le site dans un home à part dans un contexte "mono utilisateur" et encore. Tous les "documents" attachés à une application n'appartiennent pas spécialement à un utilisateur et c'est pourquoi le "home" de ces applications est bien dans /var/lib ou /var/www (cf apache, mysql, munin et bien d'autres).
Imaginons par exemple que l'utilisateur mando héberge les "pages" en question et qu'il décide brusquement de restreindre l'accès à son home. Et bien c'est dommage mais là avec lien symbolique on sera coincé (pas avec un mount bind qui est exécuté par root) mais conceptuellement ce dossier n'a rien à faire dans son home. Je rappelle au passage qu'un utilisateur peut dégager de son home un fichier qui ne lui appartient pas même s'il n'a pas les droits dessus (ben oui.. c'est son home :p).
Preuve :
(mando@aldur) (~) $ su - Mot de passe : (root@aldur) (~) # touch /home/mando/pouet.txt (root@aldur) (~) # logout (mando@aldur) (~) $ ls -l /home/mando/pouet.txt -rw-r--r-- 1 root root 0 1 oct. 11:03 /home/mando/pouet.txt (mando@aldur) (~) $ rm /home/mando/pouet.txt rm : supprimer fichier vide (protégé en écriture) « /home/mando/pouet.txt » ? y (mando@aldur) (~) $ ls -l /home/mando/pouet.txt ls: impossible d'accéder à /home/mando/pouet.txt: Aucun fichier ou dossier de ce type
Bref... laissons les pages à leur place et mettons simplement mando... dans www-data... comme c'est prévu à la base.
Bonne chance
lami20j
Messages postés
21331
Date d'inscription
jeudi 4 novembre 2004
Statut
Modérateur, Contributeur sécurité
Dernière intervention
30 octobre 2019
3 567
Modifié par lami20j le 1/10/2010 à 12:28
Modifié par lami20j le 1/10/2010 à 12:28
Salut,
Bon stop je vois trop de trucs qui me piquent les yeux :)
Ca me pique aussi ;-)))
Ceci empêche que des fichiers du dossier personnel de l'utilisateur changent de propriétaire (et donc corrompent la session graphique en cours).
Il reste à montrer un exemple ou l'edition d'un fichier texte sudo change le propriétaire du fichier puisque je n'ai pas encore vu ça.
Je vois ça sur ton lien
"Utiliser sudo pour exécuter des applications en mode graphique peut causer des problèmes dans votre session utilisateur courante, vous empêchant de poursuivre votre travail.1) "
Ben, depuis toujours j'ai utilisé sudo et je n'ai jamais eu des problèmes concernant la poursuite de mon travail ;-)
Je ne contredis pas, mais je n'aime pas des affirmation lancées comme ça sans donner quelques exempler pour soutenir l'afirmation.
L'application gksudo sers à ouvrir les applications graphiques depuis le menu avec Jerry ;-) (à ajouter dans gconf si ce n'est pas le cas, par exemple pour un autre utiilsateur vu que pour le 1er c'est ok), mais si on utilise le terminal, franchement j'ai besoin d'un peu plus pour être convaincu ;-)
Bon stop je vois trop de trucs qui me piquent les yeux :)
Ca me pique aussi ;-)))
Ceci empêche que des fichiers du dossier personnel de l'utilisateur changent de propriétaire (et donc corrompent la session graphique en cours).
Il reste à montrer un exemple ou l'edition d'un fichier texte sudo change le propriétaire du fichier puisque je n'ai pas encore vu ça.
Je vois ça sur ton lien
"Utiliser sudo pour exécuter des applications en mode graphique peut causer des problèmes dans votre session utilisateur courante, vous empêchant de poursuivre votre travail.1) "
Ben, depuis toujours j'ai utilisé sudo et je n'ai jamais eu des problèmes concernant la poursuite de mon travail ;-)
Je ne contredis pas, mais je n'aime pas des affirmation lancées comme ça sans donner quelques exempler pour soutenir l'afirmation.
L'application gksudo sers à ouvrir les applications graphiques depuis le menu avec Jerry ;-) (à ajouter dans gconf si ce n'est pas le cas, par exemple pour un autre utiilsateur vu que pour le 1er c'est ok), mais si on utilise le terminal, franchement j'ai besoin d'un peu plus pour être convaincu ;-)
[...]Ensuite il n'y a pas vraiment de raison de stocker le site dans un home à part dans un contexte "mono utilisateur" et encore[..]
Dans une perspective de serveur en prod soit.. en tant que monoutilisateur perso je vois pleins d'avantages.
Poste desktop : je ne sépare pas /var > /home a beaucoup plus d'espace (je ne sais pas combien je vais avoir de projets en cours)
Il est plus évident de penser à backuper /home que /var
Pour un serveur web/php local, un lien symbolique est plus rapide qu'un bind.. mais attention, je ne dis pas que j'ai raison :) j'expose juste un point de vue
Dans une perspective de serveur en prod soit.. en tant que monoutilisateur perso je vois pleins d'avantages.
Poste desktop : je ne sépare pas /var > /home a beaucoup plus d'espace (je ne sais pas combien je vais avoir de projets en cours)
Il est plus évident de penser à backuper /home que /var
Pour un serveur web/php local, un lien symbolique est plus rapide qu'un bind.. mais attention, je ne dis pas que j'ai raison :) j'expose juste un point de vue
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
1 oct. 2010 à 15:14
1 oct. 2010 à 15:14
C'est juste une remarque pour faire prendre les habitudes, après le monde de Linux étant un monde libre, chacun fait comme il l'entend ;-)
Par rapport au partitionnement c'est justement pour ça que /var n'est pas forcément sur la même partition que / et ce serait clairement plus indiqué pour un serveur web ou de base de données. Idem pour /tmp. Note que des solutions comme lvm sont typiquement là pour répondre aux problématiques de partitionnement.
Par rapport au partitionnement c'est justement pour ça que /var n'est pas forcément sur la même partition que / et ce serait clairement plus indiqué pour un serveur web ou de base de données. Idem pour /tmp. Note que des solutions comme lvm sont typiquement là pour répondre aux problématiques de partitionnement.
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
Modifié par mamiemando le 1/10/2010 à 15:31
Modifié par mamiemando le 1/10/2010 à 15:31
Non non la discussion est intéressante, boisdulait :
- Elle montre clairement que les étapes de partitionnement sont loin d'être anodine.
- Elle montre également les problématique lvm ou de bind qu'on pourrait avoir dans un contexte "professionel" ou pour d'autres serveurs (ftp...)
- Cette discussion montre aussi la prudence qu'on doit avoir vis-à-vis des liens symboliques et sur comment "jailer" un client dans une sous partie de l'arborescence Linux.
- Enfin c'est aussi l'occasion de montrer pourquoi les pages apaches sont dans /var et de réviser tout ce qui se rapporte à la FHS (File Hierachy Standard).
Je tiens d'ailleurs à en profiter pour m'excuser si certaines personnes ont été froissées par "ça pique les yeux", je n'ai pas voulu être vexante auprès de qui que ce soit.
Et effectivement il y a des chances que /var soit dans / s'il a choisi une installation par défaut.
C'est d'ailleurs une raison pour laquelle j'installe souvent / et /home dans une même partition quand je ne peux pas/veux pas faire de lvm, même si cela complique une réinstallation de linux (dieu merci... ça n'arrive jamais car c'est un système fiable... quand on sait l'utiliser :p) et un fsck plus long tous les 30 reboots.
Bref, beaucoup de choix dépendent des personnes et du besoin : la distribution, les paquets, les choix tecnhiques et la manière dont on les administre. Je trouve que ces quelques messages permettent de mettre en évidence et les inconvénients de chaque approche et forment ainsi un "hors sujet" plutôt intéressant.
- Elle montre clairement que les étapes de partitionnement sont loin d'être anodine.
- Elle montre également les problématique lvm ou de bind qu'on pourrait avoir dans un contexte "professionel" ou pour d'autres serveurs (ftp...)
- Cette discussion montre aussi la prudence qu'on doit avoir vis-à-vis des liens symboliques et sur comment "jailer" un client dans une sous partie de l'arborescence Linux.
- Enfin c'est aussi l'occasion de montrer pourquoi les pages apaches sont dans /var et de réviser tout ce qui se rapporte à la FHS (File Hierachy Standard).
Je tiens d'ailleurs à en profiter pour m'excuser si certaines personnes ont été froissées par "ça pique les yeux", je n'ai pas voulu être vexante auprès de qui que ce soit.
Et effectivement il y a des chances que /var soit dans / s'il a choisi une installation par défaut.
C'est d'ailleurs une raison pour laquelle j'installe souvent / et /home dans une même partition quand je ne peux pas/veux pas faire de lvm, même si cela complique une réinstallation de linux (dieu merci... ça n'arrive jamais car c'est un système fiable... quand on sait l'utiliser :p) et un fsck plus long tous les 30 reboots.
Bref, beaucoup de choix dépendent des personnes et du besoin : la distribution, les paquets, les choix tecnhiques et la manière dont on les administre. Je trouve que ces quelques messages permettent de mettre en évidence et les inconvénients de chaque approche et forment ainsi un "hors sujet" plutôt intéressant.
