[Apache] Configuration, virtualhosts et suexec

[kamui57]

Hello.

Je me fais un serveur web sur mon pc, pour l'instant uniquement en local. J'aimerais que les scripts php soient exécutés non pas par le serveur, mais par leur proprio, pour éviter des problèmes de permissions lors de création/d'écriture dans des fichiers, j'ai vu deux modules apache permettant de le faire, mpm-itk et suexec. Suexec étant fourni avec apache et mentionné dans le wiki, je me suis orientée vers lui.

J'aimerais pouvoir plus tard donner la possibilité à d'autres utilisateurs de gérer des sites sur le pc, ça peut être utile pour des tests. Donc (source de l'idée) pour chaque site (virtualhost) j'ai un utilisateur, dédié uniquement au site, faisant partie du groupe ftponly (vu ça sur le même lien, j'ai jamais mis en place de ftp/sftp mais jsuppose que ce groupe peut servir à ce moment là)

Donc j'ai abouti à la configuration plus bas à l'aide ce ces deux pages (un blog, un wiki) et j'aimerais avoir vos remarques, parce que je pense que c'est plus facile de corriger les erreurs avant les manips qu'après .

/etc/httpd/conf/httpd.conf
/etc/httpd/conf/extra/httpd-vhosts.conf
Création des utilisateurs, groupes et chmod

Code : Tout sélectionner

groupadd ftponly

useradd -s /bin/false -d /srv/http/vhosts/genealogie -m -g ftponly genealogie

mkdir -p /srv/http/vhosts/genealogie/{htdocs/cgi-bin,tmp,log}

chown genealogie:ftponly /srv/http/vhosts/genealogie/{htdocs/cgi-bin,tmp,log}

Les noms de domaines j'ai mis ça au pif, j'ai aucune idée de comment le gérer pour l'instant. Faudra faire ça avec un /etc/hosts ou un serveur bind ? De toute façon vaut mieux que le serveur fonctionne déjà non ?

[FoolEcho]

Salut,
Je ne comprends pas ta démarche. En tous cas, je ne vois pas l'intérêt des serveurs virtuels pour ce que tu veux faire.

J'aimerais que les scripts php soient exécutés non pas par le serveur, mais par leur proprio, pour éviter des problèmes de permissions lors de création/d'écriture dans des fichiers,

La création et l'exécution sont deux choses différentes.
Ton code php sera toujours interprété par le serveur.
Pour les permissions quand tu crées des fichiers, si tu as plusieurs personnes qui gèrent un site, il te suffit qu'ils aient accès aux mêmes répertoires avec des droits communs et suffisants pour travailler dessus, c'est à ça que servent les groupes... Le serveur lui s'en fiche à qui est le fichier (tu n'as qu'à faire l'essai si tu ne me crois pas, en attribuant à un autre utilisateur l'un de tes fichiers dans ton espace web).

Et apache te fournit le comportement de base pour que chaque utilisateur ait son propre site (~/public_html/ avec droits 755).

Un serveur virtuel ne sert "qu'à" attribuer différents noms de domaines à une même adresse ip.

[kamui57]

En fait je veux ne pas attribuer 777 aux dossiers pour réussir à faire (ce code a été testé dans mon public_html)

Code : Tout sélectionner

<?php 
ini_set("display_errors",1);

file_put_contents("test.txt", "test écriture");
?>

sans

Warning: file_put_contents(test.txt): failed to open stream: Permission denied in /home/stepharch/public_html/phpinfo.php on line 4

et si un script php par exemple un cms crée un fichier, je veux pouvoir le manipuler comme s'il était à moi. D'où mon idée de suexec, mais si vous avez une meilleure idée, je veux bien

Voici mes permissions

Code : Tout sélectionner

19:45:53 stepharch@toshi:~ 112$ ls -l /home|grep $USER
drwxr-xr-x 171 stepharch users 24576 13 oct.  15:42 stepharch
19:45:58 stepharch@toshi:~ 113$ ls -l |grep public
drwxr-xr-x 10 stepharch users      40960 13 oct.  19:40 public_html
19:46:01 stepharch@toshi:~ 114$ ls -l public_html/phpinfo.php
-rwxr-xr-x 1 stepharch users 90 13 oct.  19:40 public_html/phpinfo.php
19:46:04 stepharch@toshi:~ 115$ id
uid=1000(stepharch) gid=100(users) groupes=100(users),4(adm),7(lp),10(wheel),14(uucp),19(log),91(video),92(audio),
93(optical),94(floppy),95(storage),96(scanner),98(power),150(wireshark)

car des scripts php vont être amenés à écrire dans des fichiers.

[tuxce]

Ton code php sera toujours interprété par le serveur.

Sans Suexec, ça sera toujours par l'utilisateur par défaut, or justement il veut compartimenter les sites, d'où le suexec.
Quant aux vhosts, ce n'est pas comparable au module userdir, c'est quand même meilleur d'accéder à un site par un nom de domaine identifiable de par nom_de_domaine_generic/~utilisateur

[FoolEcho]

c'est quand même meilleur d'accéder à un site par un nom de domaine identifiable de par nom_de_domaine_generic/~utilisateur

Oui, mais pour un serveur local, je trouve ça abusé.

Désolé, il a fallu que je me replonge là-dedans, le temps de retester un brin.

En fait je veux ne pas attribuer 777 aux dossiers pour réussir à faire (ce code a été testé dans mon public_html)

Ça, pas le choix.

et si un script php par exemple un cms crée un fichier, je veux pouvoir le manipuler comme s'il était à moi. D'où mon idée de suexec, mais si vous avez une meilleure idée, je veux bien

Applique le setgid sur le répertoire où tu stockes tes fichiers créés par script (777):

Code : Tout sélectionner

chmod +s /le/repertoire/de/stockage/

Quand ton script php générera un fichier, il appartiendra certes à "http" (l'identité de celui qui lance le serveur), mais il sera membre du groupe auquel le répertoire appartient (et plus "http" du fait du "drwsrwsrwx" )... et donc si tu t'es rajouté avec tes petits camarades dans un groupe donné, il suffira de changer les permissions sur le fichier créé pour que tout ce petit monde puisse y mettre sa pagaille:

Code : Tout sélectionner

<?php
ini_set("display_errors",1);

if (!$fp = fopen("/le/repertoire/de/stockage/fichier.txt","a")) {
echo "Echec de l'ouverture du fichier";

exit;

}
fwrite ($fp, "Hello, world ! -truc-vachement-original-s-il-en-est");  
chmod ("/le/repertoire/de/stockage/fichier.txt", 0775);
fclose ($fp);

?>

Le fichier appartient à "http", mais les permissions sur le groupe te permettront de faire ce qu'il faut.

Tout ça sans toucher à la configuration d'apache ou de php (bon, faut quand même pas avoir une scission avec root si tu veux avoir ton groupe dédié ).

[tuxce]

Oui, mais pour un serveur local, je trouve ça abusé.

pour l'instant uniquement en local

J'aimerais pouvoir plus tard donner la possibilité à d'autres utilisateurs de gérer des sites sur le pc

Mais de toute façon, ça ne coute rien de faire des vhosts...

Pour la question des droits, mettre des +s ne résout pas la problématique et même l'aggrave, le but ici si j'ai bien saisi est de compartimenter les sites, quelque soit le bricolage effectué, sans suexec, les scripts se lancent avec "http" et donc, ce que peut faire l'utilisateur X, Y pourra le faire; pour être plus clair, X crée un fichier, Y peut le lui effacer etc.

[FoolEcho]

Je ne vois pas pourquoi tu dis que ça aggrave la situation.

les scripts se lancent avec "http" et donc, ce que peut faire l'utilisateur X, Y pourra le faire; pour être plus clair, X crée un fichier, Y peut le lui effacer etc.

J'ai surtout compris (au deuxième message) qu'il voulait créer des fichiers par le site pour les modifier derrière par son utilisateur (pas par le web, donc: sinon c'est .htaccess et compagnie), donc la gestion des groupes suffit amplement... mais j'ai peut-être mal compris.

[kamui57]

Le problème que j'ai eu chez un hébergeur mutualisé, c'est que j'installais des cms pour tester, et après en voulant en supprimer ça marchait pas (pas le droit de supprimer certains fichiers/dossiers) car ils avaient été crées par le serveur lors de l'installation. Dans un post du forum que je ne trouve plus, l'admin disait que pour résoudre ça il devait mettre un module type suexec mais que ça prenait trop de ressources alors il ne le ferait pas. Exemple d'un problème

Un autre hébergeur explique avoir résolu le problème, je viens de répondre pour lui demander des précisions

Léobaillard a dit :
Ouep, exactement. En fait, au point de vue technique, dans la V3, chacun aura un utilisateur en "dur" et son serveur virtuel apache. Donc, tous les fichiers créés soit par PHP, soit par FTP vous appartiendront (et non plus à www-data comme c'est le cas actuellement). Vous serez donc libres de manipuler comme bon vous semble vos permissions mais attention à ne pas faire de bêtises, au quel cas certains de vos fichiers ne pourraient même plus êtres accessibles pas vous Et oui Je vous conseille de vous documenter sur les chmods : http://fr.wikipedia.org/wiki/Chmod .

Sur ce sujet quelqu'un conseille d'utiliser mpm-itk.

[benjarobin]

@kamui57 Je ne sais pas quel hébergeur mutualisé tu utilisais mais cela fait assez peur ce genre de configuration...
Sinon pour supprimer les fichiers récalcitrant il aurait suffit de faire un .php qui aurait supprimer les fichiers

[kamui57]

Qu'est-ce qui fait peur ?

[tuxce]

Je ne vois pas pourquoi tu dis que ça aggrave la situation.

ce que peut faire l'utilisateur X, Y pourra le faire; pour être plus clair, X crée un fichier, Y peut le lui effacer

Ce cas pour moi, serait grave. Et il l'est plus que de ne pas pouvoir modifier un fichier d'où l'aggravation

J'ai surtout compris (au deuxième message) qu'il voulait créer des fichiers par le site pour les modifier derrière par son utilisateur

J'ai plutôt compris qu'il voulait en gros héberger plusieurs utilisateurs (gérer un hébergement mutualisé), comme quoi ...
Enfin peu importe, en gros, ce que j'ai voulu dire, c'est que pour séparer 2 (ou plus) utilisateurs sur un serveur web tout en leur laissant les même droits, à part lancer leurs scripts / programmes sous 2 utilisateurs différents, je vois pas trop, et pour ça, suexec, mod_suphp, mpm-itk, mpm-peruser etc. sont autant d'implémentations qui se basent sur ce principe.

[EDIT]Tiens, je suis tombé sur ça, ça semble pas mal: http://blog.stuartherbert.com/php/categ ... -platform/
Bon, si le but n'est pas de faire du mutualisé, c'est HS, mais le lien reste intéressant

[kamui57]

Ben vous avez tous les deux raison
- héberger plusieurs utilisateurs : héberger mes pages d'une part, et si ma mère se met au web, j'aimerais qu'elle puisse avoir des pages sur mon pc accessibles depuis le sien, et qu'elle les gère elle-même d'autentrere part
- que si elle installe (soyons fous) un cms/script php qui lui crée des fichiers dans son espace, qu'elle puisse les modifier, supprimer elle-même sans passer par un script php

Tuxce : ok donc ya bien à choisir entre suexec, mod_suphp, mpm-itk, mpm-peruser. Tu as déjà fait un truc dans le genre ? Si oui tu conseillerais quoi ?

ce que peut faire l'utilisateur X, Y pourra le faire; pour être plus clair, X crée un fichier, Y peut le lui effacer

Ce cas pour moi, serait grave. Et il l'est plus que de ne pas pouvoir modifier un fichier d'où l'aggravation

j'approuve.

edit : merci pour le lien, je regarderai ça.

[FoolEcho]

Désolé d'insister, mais:

et si ma mère se met au web, j'aimerais qu'elle puisse avoir des pages sur mon pc accessibles depuis le sien, et qu'elle les gère elle-même d'autentrere part

Ce qui revient strictement à: utilisateur X et Y ont accès aux mêmes fichiers donc: groupe & droits appropriés.

- que si elle installe (soyons fous) un cms/script php qui lui crée des fichiers dans son espace, qu'elle puisse les modifier, supprimer elle-même sans passer par un script php

Ce qui revient à: groupe restreint à mon seul utilisateur (cf message précédent): utilisateur = moi ; groupe = moi (si ça en choque certains: en théorie root est le seul utilisateur de son groupe).

J'ai rien contre le fait de mutualiser et de faire mumuse avec la configuration d'apache, mais j'en vois pas l'intérêt.

[tuxce]

Tuxce : ok donc ya bien à choisir entre suexec, mod_suphp, mpm-itk, mpm-peruser. Tu as déjà fait un truc dans le genre ? Si oui tu conseillerais quoi ?

Je n'ai fait que tester et pas tous, mpm-itk n'étant pas par défaut partout (sur arch, ça semble être le cas), les différents articles semblent dire que mpm-itk donne de meilleures performances et j'ai eu des soucis avec mod_suphp.

Désolé d'insister, mais:

et si ma mère se met au web, j'aimerais qu'elle puisse avoir des pages sur mon pc accessibles depuis le sien, et qu'elle les gère elle-même d'autentrere part

Ce qui revient strictement à: utilisateur X et Y ont accès aux mêmes fichiers donc: groupe & droits appropriés.

kamui57: utilisateur X
sa mère: utilisateur Y
Sans suexec ou équivalent sa mère pourra effacer les fichiers de kamui57 tout simplement parce qu'il les aura créé depuis un script lancé par "http" et qu'elle aura les mêmes droits vu que son script sera aussi lancé par "http" !

- que si elle installe (soyons fous) un cms/script php qui lui crée des fichiers dans son espace, qu'elle puisse les modifier, supprimer elle-même sans passer par un script php

Ce qui revient à: groupe restreint à mon seul utilisateur (cf message précédent): utilisateur = moi ; groupe = moi (si ça en choque certains: en théorie root est le seul utilisateur de son groupe).

Je comprends même pas pourquoi on parle de groupes et d'utilisateurs, par défaut et sans les modules permettant de lancer un processus sous un autre utilisateur, c'est équivalent à avoir un seul login/mdp, donc si t'as accès à suppression/création/... comment tu veux savoir qui est qui ou protéger quelque chose ?

Ou alors l'utilisateur voulant protéger un fichier doit créer un fichier n'appartenant pas à "http" (ni à son groupe), applique un o-w (sans oublier le -w du dossier), puis lui remettre les droits quand un de ses scripts voudra le modifier et enfin lui re enlèver les droits...

Prenons l'exemple de php, une fois dans le script, ce n'est pas apache qui gère, mais php, donc on oublie tout ce qui est .htaccess etc., il nous reste les relatives protections du php.ini (safe_mode, open_basedir,...) qui peuvent toutes être contournées par des extensions.

J'ai rien contre le fait de mutualiser et de faire mumuse avec la configuration d'apache, mais j'en vois pas l'intérêt.

J'ai bien compris que sur son propre poste, en local en plus, juste pour tester si ça se trouve etc., ça n'a pas d'intérêt. J'irai même plus loin, pour l'instant aucune modification/configuration n'a d'intérêt parce que si ça se trouve, kamui57 sera sollicité pour toutes les modifications, du coup "http" est largement suffisant ...

Mais sauf erreur, la question est de gérer plusieurs utilisateurs avec les mêmes droits tout en les protégeant, si tu ne lances pas les processus sous plusieurs utilisateurs, tu n'as à ma connaissance aucune protection.

[FoolEcho]

Ou alors l'utilisateur voulant protéger un fichier doit créer un fichier n'appartenant pas à "http" (ni à son groupe), applique un o-w (sans oublier le -w du dossier), puis lui remettre les droits quand un de ses scripts voudra le modifier et enfin lui re enlèver les droits...

Oui, ça devient imbuvable.

Donc va pour suexec. En passant (ça peut être plus simple pour un serveur local et ça n'est pas mentionné dans le wiki ), tu peux le faire sans hôte virtuel:
http://httpd.apache.org/docs/2.3/fr/suexec.html#usage
http://httpd.apache.org/docs/2.3/fr/howto/cgi.html (voir répertoires utilisateurs par exemple)