Développer/tester sous utilisateur non-root un site en php

Support Debian
#1

Bonjour,

Je suis en train de développer/tester en local un site en php - avec l’éditeur Bluefish - sur ma machine Debian7 (Gnome).

Pour ce faire j’ai installé apache2, php5 et mysql-server. Ensuite j’ai créé un dossier /site_test dans /var/www. Pour créer ce dossier j’ai du ouvrir Bluefish à partir de ma console root car je n’ai accès en écriture au dossier /var que sous root.

Mais pour développer et tester le site cette solution :

  • n’est pas très pratique, par exemple lorsque je veux télécharger une image dans var/www/site_test à partir d’internet via mon navigateur, qui lui ne fonctionne pas sous l’utilisateur root ;
  • n’est pas très sécurisée dans la mesure où j’ai lu qu’il n’est pas recommandé de travailler sous root en mode graphique (même si ici ce mode graphique est limité au seul Bluefish fonctionnant “au nom du superutilisateur”).

Je voudrais donc pouvoir développer/tester mon site php avec Bluefish en utilisateur non-root (c-à-d sous l’utilisateur sous lequel j’utilise habituellement mon ordi). Pour ce faire j’envisage de donner les droits d’utilisation de /site_test à cet utilisateur en faisant :
/var/www$ chown site_test -R

Question : est-ce la meilleur solution pour pouvoir développer/tester mon site php avec Bluefish en utilisateur non-root ?

Merci

#2

Salut,

[quote=“François”]Question : est-ce la meilleur solution pour pouvoir développer/tester mon site php avec Bluefish en utilisateur non-root ?
[/quote]

[mono]sudo[/mono] ?

[mono]$ man sudoers[/mono] et le Wiki : Root-su-sudo.

#3

A mon avis il vaut mieux définir l’utilisateur/groupe propriétaire et les droits d’accès au répertoire qui contient le site.

#4

Oui Pascal, mais pour faire propre, je recommanderais de tout mettre dans /var/www/mon-site (voire avec mon-site un ln -s vers un repertoire dans le home de l’utilisateur). Ce répertoire ayant évidement les droits en écriture pour l’utilisateur non root.
Il faudra créer un virtualhost pour accéder à localhost/mon-site

#5

Merci pour vos propositions.

Belzébuth propose (si j’ai bien compris) d’accorder à l’utilisateur non-root les droits de root sur les fichiers que non-root crée/modifie avec Bluefish.
Cette solution ne me paraît pas idéale en termes de sécurité pour ce qui concerne ce sujet.

J’ai appliqué la solution de PascalHambourg et piratebab :

1° Faire de francois le propriétaire du répertoire /var/www/site_test/ (et ses sous-répertoires) :

2° Ajouter le droit x à l’utilisateur sur ce répertoire (et ses sous-répertoires) :

3° Créer un lien symbolique du répertoire /home/francois/mes_sites/site_test vers le répertoire /var/www/site_test/ :

4° Vérifier :

#6

Quel est le but de cette action ? Piratebab suggérait plutôt l’inverse.

#7

Bein le seul intérêt que je vois c’est de pouvoir travailler à partir de mon /home. C’est du moins comme cela que j’interprète la proposition de Piratebab. Ce que j’ai fait n’est-ce pas désigner /var/www/site_test comme la source ? (qu’il ne faut donc pas supprimer).

[size=85]PS : c’est la première fois que j’utilise des liens --> j’ai peut-être pas encore bien tout pigé …[/size]

#8

c’était bien ma sugestion. Travailler dans son home, et faire pointer /var/www/mon-site vers le repertoire dans home.

#9

Pour lever toute ambiguïté au niveau de la sémantique voici ce qui dit man ln :
ln CIBLE NOM_DU_LIEN

J’utilisais donc le terme “source” alors que je devais dire “cible”.

Dans un lien symbolique le fichier “lien” n’est lié que indirectement à l’inode du fichier “cible”, en l’occurrence via ce fichier cible (alors que dans un lien physique le fichier “lien” est lié directement à l’inode du fichier “cible”, donc sans passer par l’intermédiaire de ce fichier “cible”).

[size=85]Source : http://fr.openclassrooms.com/informatique/cours/reprenez-le-controle-a-l-aide-de-linux/manipuler-les-fichiers[/size]

Donc dans ce que j’ai fait, soit :
$ ln -s /var/www/site_test/ mes_sites/

  • /var/www/site_test est le répertoire “cible” ;
  • home/françois/mes_sites/site_test est le répertoire “lien”.

Donc - si j’ai bien compris - lorsque piratetab dit “faire pointer /var/www/mon-site (PS : je suppose qu’en écrivant “mon-site” il veut dire en fait “site_test”) et non pas vers le répertoire dans home” il signifie que le répertoire “cible” (c-à-d : “ce sur quoi on fait pointer”) devrait être home/françois/mes_sites/site_test, soit le contraire de ce que j’ai fait.

Or l’intérêt de ce que j’ai fait est (encore une fois : si j’ai bien compris le “quoi” et le “comment” des liens …) :

  • de travailler à partir de home ;
  • de réduire le risque sur la cible en travaillant sur le lien.

Par contre je ne vois pas à quoi servirait :
$ ln -s /mes_sites/site_test /var/www/

Bon, vu que vous êtes bien plus expérimentés que moi c’est certainement vous qui avez raison et moi qui me trompe. Mais le problème c’est :

  • que je ne vois pas où je me trompe dans mon raisonnement ;
  • ce que vous voulez faire précisément en choisissant pour cible : “var/…” plutôt que “home/…”.
#10

L’idée, c’est que les fichiers soient physiquement dans /home/françois/mes_sites. C’est donc la cible.
Le lien, lui, est vu comme une fléche qui pointe en direction de la cible. /var/www/site_test ne contient rien physiquement.
Lorsque tu tentes d’ouvrir /var/www/site_test tu es en réalité redirigé vers /home/françois/mes_sites qui contient les données

#11

Ça je comprends bien.

Mais pourrais-tu :

(i) dire pour quelle(s) raison(s) tu recommandes - concernant cette liaison - de stocker physiquement les fichiers dans “/home/…” plutôt que dans “/var/…” ;

(ii) dire en quoi le raisonnement suivant est erroné :

“Si l’on décide de dédoubler les fichiers par lien, il me paraît plus rationnel de les stocker physiquement là où l’on ne travaille pas physiquement (var/…), puisque l’endroit où l’on travaille physiquement (home/…) est celui où l’on est susceptible de commettre des erreurs de manipulation pouvant par exemple provoquer la destruction des fichiers (ce qui dès lors ne serait pas grave puisqu’ils seraient en fait physiquement situés ailleurs).”

#12

Tu abordes 2 problèmes différents:

  • travail dans /var ou /home: /var est n’est pas un répertoire de travail. C’est pour cela que normalement l’utilisateur non root n’a pas les droits d’écrire dedans. On travaille cdans son home, avec tout les droits pour l’utilisateur courant. Faire pointer /var/www/site_test n’est qu’une astuce rapide mais pas trés propre pour éviter de donner trop de droits dans /var/www

  • avec un lien on ne dédouble pas les fichiers! on leur donne un accès depuis 2 répertoire différents! Si tu veux travailler vraiment proprement, il te faut un répertoire de travail dans lequel tu fais tes modifications, puis lorsque tu as quelque chose de cohérent, tu pousses le tout dans un répertoire utilisé par le serveur web. Mais si tu en es là, autant utiliser un gestionnaire de version. C’est un petit investissement en temps pour le prendre en main, mais très rapidement compensé par la souplesse que cela amène dans ton travail.

#13

Oui, évidemment. On est bien d’accord là-dessus.

En quoi cela donne-t-il moins de droits à écrire dans /var/www, que ce soit par rapport à la situation sans lien (avec droit d’écriture sur var/www/site_test), ou par rapport à la situation où c’est /home/françois/…/site_test que l’on “fait pointer” sur var/www/site_test ?

#14

C’est surtout un aspect pratique. Tu n’as dans un cas qu’un, dans l’autre cas tout un répertoire. Si tu veux revenir à la situation d’origine, tu n’as qu’un lien à supprimer.
autre aspect pas encore abordé: la sauvegarde. Si tu fais bien les choses, tu sauvegardes ton /home régulièrement, et donc ton travail sur ton site.
Mais comme je te l’ai écrit, cela ne reste qu’un bricolage. Pour travailler vraiment proprement, il faut travailler dans son /home, et “pousser” les modifications dans /var/www pour valider les modifs.
Si tu veux vraiment voir “en tant réel” l’effet de tes modifications, il faut utiliser un IDE qui intègre un serveur web.

#15

Donc si je t’ai (enfin) bien compris piratebab tu proposes de créer un lien non pas en plus mais bien à la place de la solution proposée par PascalHambourg. Ainsi même si le propriétaire de var/www/site demeure root, on peut quand même donner l’accès en écriture à l’utilisateur non-root en faisant pointer var/www/site vers home/non-root/site :
# ln -s /home/nonroot/site /var/www
Cependant avec cette solution http://localhost/site n’est plus accessible, et pour le rendre accessible il faut créer un virtualhost.

Est-ce bien cela que tu proposes ?

#16

Pas tout à fait.
Tes fichiers sont dans /home/nonroot/site
dans/var/www, tu crées un lien

tu peux essayer d’accéder à localhost/site, mais il ne devrait pas étre accessible. Si il l’est, tant mieux, sinon il faut créer un virtual host