Forum Programmation.web Dossier de developpement web sous linux

Posté par  . Licence CC By‑SA.
Étiquettes :
0
3
sept.
2025

Bonjour,
Le dossier de developpement de(s) site(s) web sous linux semble etre /var/www.
Quels sont les inconvénients d'utiliser /home/$USER/www a la place ? Est-ce que ça viole une régle ? De sécurité ?
Est-ce qu'on peut trouver un débat sur cette question quelque part ?
Merci
Eric

  • # Securite local de linux

    Posté par  . Évalué à 2 (+1/-0).

    Bonjour
    Pas facile si on la jamais fait mais je dirai que par défaut les package sont configurés pour var/ www donc penser à chaque erreur que ça peut venir de la

    Html php perl tant que pas d'écriture dans le répertoire ça ne devrait rien faire
    .
    Si base de donnee ou ecriture de fichier
    Penser à vérifier selinux
    Mettre www ou apache ou autre en groupe proprietaire de ton repertoire www et ajouter le user dans le groupe apache

    Franck

  • # Ça dépend...

    Posté par  (Mastodon) . Évalué à 4 (+1/-0).

    En soit tout est possible, mais tu ne donnes pas tous les détails de ce que tu imagines.

    Est-ce qu'il y a plusieurs $USER ? Est-ce que le serveur tourne sur le compte root (et donc sur les ports réservés type 80/443) ? Est-ce que les fichiers auront les droits du user/group ou continueront d'être www-data ?

    Ce qu'il faut éviter à tout prix c'est que un serveur tournant sous root lise des fichiers ouverts à n'importe qui.

    Mais pourquoi tu veux faire ça au fait ? Peut-être qu'il y a mieux à faire que les mettre dans le $USER selon ton besoin réel.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Ça dépend...

      Posté par  . Évalué à 1 (+0/-0).

      Bonjour,
      Il n'y a qu'un user : moi.
      Le PC est sous Debian 13, le compte apache est www-data, sur le port 80, il faut au moins que le serveur puisse écrire dans les dossiers de log et générer des fichiers à télécharger.
      Tout ça se situe dans le cadre de dev à titre de hobby, je ne developpe pas d'applis pro, mais des choses privées, pour mon plaisir. Les applis sont developpées avec codeigniter et finissent (parfois) sur un serveur mutualisé (ouvaton)

  • # conventions

    Posté par  . Évalué à 5 (+3/-0).

    Le dossier de developpement de(s) site(s) web sous linux semble etre /var/www.

    C'est juste une convention, à toi de voir si tu veux la suivre ou pas.

    Quels sont les inconvénients d'utiliser /home/$USER/www a la place ? Est-ce que ça viole une régle ? De sécurité ?

    non aucune. Mets bien ce que tu veux ou tu veux en fait. Après, comme plein de docs suivent cette convention, ben c'est plus simple à suivre plutôt que de faire des translations à chaque path.

    Est-ce qu'on peut trouver un débat sur cette question quelque part ?

    Peut-être dans le FHS? https://fr.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

    • [^] # Re: conventions

      Posté par  (site web personnel) . Évalué à 5 (+3/-0).

      FHS pointe plutôt vers /srv/www de nos jours.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: conventions

        Posté par  . Évalué à 6 (+5/-0).

        Bonjour

        C'est aussi ce que dit la page man retournée par la commande :

        man hier

        … et dans ce royaume, ceux qui y voient un peu plus clair sont souvent très mal vus.

        • [^] # Re: conventions

          Posté par  . Évalué à 7 (+5/-0).

          Par contre, c'est dur d'avoir des infos plus récentes !

          $ man aujourd\'hui
          No manual entry for aujourd'hui
          

          Matricule 23415

        • [^] # Re: conventions

          Posté par  (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 05 septembre 2025 à 21:34.

          "[…] par la commande : man hier"
          Mais, est-ce la bonne ?

          • [^] # Re: conventions

            Posté par  (Mastodon) . Évalué à 4 (+1/-0).

            Mais, est-ce la bonne ?

            Je l'ai !

            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

            • [^] # Re: conventions

              Posté par  . Évalué à 3 (+2/-0).

              Je l'ai !

              Laisse la tranquille, elle n'y est pour rien.

              … et dans ce royaume, ceux qui y voient un peu plus clair sont souvent très mal vus.

  • # Réponse globale

    Posté par  . Évalué à 3 (+2/-0).

    Ca fait une dizaine d'années que j'utilise /home/$user/www/public pour placer mes dev web.
    $user, c'est moi.
    Je n'ai pas énormément de connaissances linux, alors je dirais dans mon langage que cette manière de fonctionner requiert d'attribuer des droits a www-data sur le dossier du $user. Alors qu'à l'inverse, avec /var/www etc , il faut attribuer des droits à $user pour pouvoir développer.
    Je préfère utiliser mon home, parce qu'il est logé sur un disque dur en totalité monté sur /home. Je peux le débrancher, le monter en usb sur une autre machine pour synchroniser/sauvegarder, bref, la belle vie.
    Mais à la suite de changements de machine, j'ai du mal à attribuer les bons droits au serveur, je me retrouve avec une erreur HTTP 403 quand j'essaie d'acceder à localhost pour afficher le phpinfo(); qui (devrait) me dit(re) que j'ai bien tout fait comme il faut.
    Alors je pose la question technique sur un autre forum, des droits et permissions à mettre en oeuvre pour m'en sortir. Y a une page tres bien faite sur le sujet ici : (https://doc.ubuntu-fr.org/tutoriel/lamp_repertoires_de_travail).
    Mais pour moi, si en opérant dans /var/www/public ça marche très bien, dès que je bascule sur /home/$user/www/public, je retombe sur l'erreur HTTP 403.
    Comme on me dit que je ne devrais pas utiliser mon home pour ça, pour des raisons de sécurité, failles etc… je me demandais si je devais perseverer dans l'erreur ou si'l fallait devenir raisonable, faire comme tout le monde et developper dans /var etc…
    Voila, c'est un peu long, mais ca vous donne le contexte.
    Merci pour vos réponses.
    Eric

    • [^] # Re: Réponse globale

      Posté par  (site web personnel, Mastodon) . Évalué à 6 (+5/-0).

      Mon avis c'est que /var/www (ou un autre équivalent) est plus safe, si tu utilises un dossier de ton home dir, ton serveur HTTP :
      * a accès à un répertoire qui donne une information utile : le nom du user que tu utilises
      * a accès potentiellement à d'autres fichiers dans ton home dir si tu te rates sur les permissions - généralement, on n'a pas à faire trop attention, vu que le homedir lui-même n'est pas traversable, mais dès lors que tu autorises www-data à le traverser, tu dois être vigilant sur les permissions à l'intérieur

      La bonne pratique est de cloisonner autant que possible ce à quoi il a accès pour limiter les dégâts en cas de compromission.

    • [^] # Re: Réponse globale

      Posté par  (site web personnel) . Évalué à 3 (+1/-0).

      Les conventions peuvent simplifier des choses. Quand on sort des conventions, on peut potentiellement en apprendre plus parce qu'il y a plein de plus ou moins gros problèmes qui apparaissent.

      Outre les permissions Unix standards, sous GNU/Linux, dès qu'on dévie des conventions, on se retrouve vite avec des problèmes deà en apprendre plus que ce qu'on voulait sur SELinux/AppArmor/TOMOYO/…

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Apache UserDir: Répertoires web utilisateurs

    Posté par  . Évalué à 4 (+2/-0).

    https://httpd.apache.org/docs/2.4/fr/howto/public_html.html

    "Si tous les cons volaient, il ferait nuit" F. Dard

    • [^] # Re: Apache UserDir: Répertoires web utilisateurs

      Posté par  . Évalué à 2 (+1/-0).

      Ca m'a l'air très bien, ca, Merci !!

      • [^] # Re: Apache UserDir: Répertoires web utilisateurs

        Posté par  . Évalué à 3 (+1/-0).

        Ca m'a l'air très bien, ca, Merci !!

        Content d'avoir pu aider ! à noter que le module mod_userdir doit être activé

        Une autre approche serait les "virtual hosts": https://httpd.apache.org/docs/2.4/fr/vhosts/name-based.html
        et d'utiliser /etc/hosts

        ainsi pour l'exemple donné dans la doc vhosts ci dessus:

        <VirtualHost *:80>
            # Le premier serveur virtuel de la liste est aussi le
            # serveur par défaut pour *:80
            ServerName www.example.com
            ServerAlias example.com
            DocumentRoot "/www/domain"       # <= it's up to you
        </VirtualHost>
        
        <VirtualHost *:80>
            ServerName other.example.com
            DocumentRoot "/www/otherdomain"
        </VirtualHost>

        (Les vHosts permettent aussi de générer des logs Apache séparés par "ServerName" si besoin ;)

        çà ferait pour /etc/hosts un truc comme:

               127.0.0.1       localhost
               127.0.O.1       www.example.com   
               127.0.O.1       other.example.com
        
        

        pour finir,

        • comme il faut que

          … le serveur puisse écrire dans les dossiers de log et générer des fichiers à télécharger. (…) Les applis sont developpées avec codeigniter

        • que ce soit avec les UserDir (plutôt orienté multi-utilisateurs) ou avec les VirtualHosts (plutôt orienté multi-sites), www-data devra avoir les droits nécessaires (et suffisants !) pour ce que tu as à faire sur les dossier concernés. CAD:

          • les logs Apache
          • les logs CodeIgniter
          • les fichiers générés par l'appli

        "Si tous les cons volaient, il ferait nuit" F. Dard

  • # lighttpd

    Posté par  (site web personnel, Mastodon) . Évalué à 3 (+0/-0). Dernière modification le 12 septembre 2025 à 15:26.

    Bonjour,

    Une chose à savoir et qui m'a fait perdre du temps: dans le packaging Debian de lighttpd, l'écriture dans les sous-dossiers de /home est interdite par une configuration au niveau du service systemd. Ce qui peut se défendre d'un point de vue sécurité, sauf si on a envie d'héberger des services web stockés dans des dossiers utilisateur et qui font des écritures dans leur propre dossier.

    J'ai mis du temps à trouver d'où pouvait bien venir l'erreur "permission denied" causée par cette configuration. C'est documenté assez clairement mais… sous forme d'un commentaire dans le fichier de définition de la unit systemd. Donc c'est très clair, mais seulement une fois que on a trouvé le problème. Et en plus, comme ce n'est pas un fichier de configuration, toute modification dedans est écrasée sans avertissement lors des mises à jour du paquet lighttpd.

    Je ne sais pas si les autres serveurs web ont une configuration similaire, et si c'est un choix spécifique à Debian.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.