Discussion :

[kanaziwok]

Comment faire alors pour qu'il ne soit ni modifiable ni supprimable ?

En gros voilà ce que je compte faire :
Une adresse http://www.domaine1.com/ qui correponds à mon site
Ce site permettra a des utilisateurs de créer leur site http://www.domaine2.com/nomdusite/
domaine1.com correspondra à la racine du disque, et domaine2.com à un dossier de ce disque.
Je me pose la question suivante :
Si domaine2.com pointe sur un dossier de domaine1.com l'utilisateur ne pourra pas descendre puis bas que là ou il pointe ?

[julp]

Si domaine2.com pointe sur un dossier de domaine1.com l'utilisateur ne pourra pas descendre puis bas que là ou il pointe ?

Définition d'utilisateur ici ?
Descendre ou remonter ?

Un client HTTP ? Non, il ne peut remonter l'arborescence.

Un utilisateur système (inclut l'exécution des scripts PHP de domaine2.com) ? Il le peut, si des mesures n'ont pas été prises.

Par contre, pour descendre (naviguer dans leurs sous-répertoires), l'un comme l'autre, c'est possible (par défaut du moins).

[kanaziwok]

Ok.
Donc comment faire pour rendre le fichier .htaccess non modifiable et non supprimable ?


Une solution auquel j'ai pensé : vu que les fichiers seront envoyé via mon site et non par un logiciel FTP client, de vérifier le contenu de chaque fichier s'il ne contient pas des fonctions comme chmod() , ssh2 , chgrp() , chown() .

[julp]

Appliquer le sticky-bit sur le répertoire parent ? Le reste n'est que question de droits (utilisateur/groupe). Enfin si vous le pouvez.

Votre test pourrait tout aussi bien être bypassé par un appel dynamique de fonction.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
function changedroits($cible, $perms) {
    return call_user_func_array(str_replace('_', '', 'c_h_m_o_d'), func_get_args());
}
 
function changedroitsbis($cible, $perms) {
    $function = "\103\110\115\117\104";
    return $function($cible, $perms);
}

[kanaziwok]

L'hébergeur que je souhaite prendre propose une connexion ssh et permet la modification du php.ini , mais bon pour le moment je vois pas de solution à mon problème à moins de posséder un serveur dédié ... ce que je ne peux malheureusement pas me permettre à l'heure actuelle .

En plus j'ai essayé avec Linux et le fichier .htaccess ne permet pas de faire du open_basedir sur certain serveur, donc en gros je crois que je peux abandonner l'idée du fait que les utilisateurs puissent envoyer des fichiers .php ou autre fichiers compromettant la sécurité du site.

[kanaziwok]

Re,

J'ai donc réussi grâce à _Mac_ à configurer en local un serveur apache avec la hierarchie suivante ( Hôtes virtuels pour l'hébergement de masse )

Deux domaines :
- XXX.domaine.tld qui pointe vers /var/www/domaine.tld/XXX/
- YYY.domaine2.tld qui pointe vers /var/www/domaine2.tld/YYY/

Le site principal sera donc présent dans /var/www/domaine.tld/www/
Les sites créés seront eux dans le repertoire /var/www/domaine2.tld/

Pour le moment voilà le fichier vhost :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
NameVirtualHost 127.0.0.1
 
UseCanonicalName Off
 
 
<Directory /var/www/domaine.tld>
	Options Indexes FollowSymLinks MultiViews
	AllowOverride All
	Order allow,deny
	allow from all
</Directory>
 
<Directory /var/www/domaine2.tld>
	Options Indexes FollowSymLinks MultiViews
	AllowOverride All
	Order allow,deny
	allow from all
</Directory>
 
<VirtualHost 127.0.0.1>
ServerName domaine.tld
ServerAlias domaine.tld *.domaine.tld
VirtualDocumentRoot /var/www/domaine.tld/%1
 
</VirtualHost>
 
<VirtualHost 127.0.0.1>
ServerName domaine2.tld
ServerAlias domaine2.tld *.domaine2.tld
VirtualDocumentRoot /var/www/domaine2.tld/%1
php_admin_value open_basedir /var/www/domaine2.tld
</VirtualHost>

Ainsi les sites créés ne peuvent pas allé au delà de /var/www/domaine2.tld/ mais j'aimerai les bloquer dans leur dossiers respectifs.

Quels sont mes options ?

[julp]

Avec l'utilisation de VirtualDocumentRoot, la situation est strictement la même : cette solution ne permet rien de plus.

[kanaziwok]

Vu que je compte prendre un RPS I chez OVH, peux-tu me conseiller sur mes options concrètement ?

- Un VirtualHost par site créé pour fixer le open_basedir ? cela va nécessiter un reload de apache donc c'est pas la meilleur méthode je présume ...
- Utilisation du module SuPHP ?
- ???

[julp]

Oui, si modification du fichier de configuration d'Apache il y a, il faudra le redémarrer pour que les changements apportés soient pris en compte.

suPHP, ou semblable, (PHP n'est plus module) pourrait effectivement être une solution. Cependant, j'ignore tout de vos besoins/désirs et, de ce que j'ai compris de ce fil, une telle solution ne semble pas [absolument] nécessaire (enfin, question de point de vue). Cela dit, vous pouvez toujours effectuer des tests (sur machine virtuelle notamment) pour avoir un aperçu de la mise en place de PHP/Apache/sites et ainsi voir quelle est la solution qui vous paraît la plus adaptée - à tous les niveaux (facilité, sécurité, performances).

[kanaziwok]

Merci, sauf que vu que je n'y connais pas grand chose, j'aimerai avoir des conseils sur la meilleur solution pour mon cas.

Parce que par exemple :
- Ajouter/Supprimer un VirtualHost par site créé, nécessite un reload du serveur apache, mais est-ce une bonne chose ? coupure du site pendant le rechargement de apache, temps de chargement de plus en plus plus long en fonction du nombre de Vhost disponible du serveur apache ... ??
- Module SuPHP : pour le moment, je n'ai fait que survoler les discussions/documentation parlant de ce module et je n'en connais pas toutes les possibilités, mais est-il possible avec mes Vhosts actuelles ce chrooter chaque utilisateur à son site respectif. Est-ce facile à faire ... ??
- Quels sont précisement les autres solutions dont je peux disposer ?

Je suis désolé de me répéter mais vu que je suis vraiment totalement débutant dans le domaine, j'ai besoin de lumière pour voir ce que je peux faire .

[julp]

Rapidement :

PHP en module, de paire avec Apache, ils partagent le même utilisateur système. Du coup, par défaut, PHP a accès à tout ce qui est en lecture pour Apache (obligé pour en donner l'accès en HTTP). La seule option c'est définir un open_basedir propre à chaque site. Je ne parlerais pas des workers modifiés (itk, peruser), ce n'est pas forcément stable et niveau performance, c'est la pire solution.

PHP, en CGI, exécuté en su*, avec attribution d'utilisateurs système différents pour chaque site, ça permet donc déjà de reposer sur les droits systèmes. Et on peut très bien définir, en complément, open_basedir pour empêcher les utilisateurs de remonter la hiérarchie du système de fichiers qu'ils n'ont théoriquement pas besoin d'atteindre (mais étant commune, il faut que l'arborescence web s'y prête).

Le "chroot", quoiqu'il en soit, est réalisé par PHP avec open_basedir. suPHP effectue un contrôle qui n'a rien à voir, il ne porte que sur le script initialement appelé (il n'a aucun pouvoir sur l'exécution du script : inclusions, manipulations de fichiers). Effectuant d'ailleurs ce contrôle par rapport au DocumentRoot, il est même parfois nécessaire de désactiver cette fonctionnalité car dans certains cas on est amené à en sortir (avec userdir par exemple).

Il faut bien faire la distinction au niveau processus, s'il y en a une, et les droits système. Je maintiens également qu'un test des différentes options n'est en rien une perte de temps, bien au contraire. Chaque solution a ses avantages, inconvénients et limites.

Par contre pour les versions >= 5.3, avec PHP en CGI, seul ou non, il est peut être possible d'employer les nouvelles possibilités du fichier php.ini (pas eu l'occasion d'expérimenter).

PS : note au sujet des VirtualDocumentRoot* : le DocumentRoot n'est pas modifié, il sera erroné (point à éventuellement prendre en compte).

[kanaziwok]

Merci encore julp,

Je vais regarder du coté de PHP en CGI, j'ai trouvé ce lien qui m'a l'air pas trop mal ( http://www.zataz.net/docs/6906/docum...gi-suexec.html )

Par contre j'aimerai avoir ton avis ou celui de quelqu'un d'autres par rapport à cette question :
Ajouter/Supprimer un VirtualHost par site créé nécessite un reload du serveur apache, mais est-ce une bonne chose ? coupure du site pendant le rechargement de apache, temps de chargement de plus en plus plus long en fonction du nombre de Vhost disponible du serveur apache ... ?? ou alors ca n'a quasi pas d'influence sur le fonctionnement du serveur et dans ce cas, là solution que j'utilise actuellement deviendrai totalement inutile .

Cordialement,

Martin.

[julp]

Ajouter/Supprimer un VirtualHost par site créé nécessite un reload du serveur apache, mais est-ce une bonne chose ?

Oui et non : il y a bien des cas où c'est vraiment nécessaire. Tout est question de durée, fréquence, moment où c'est réalisé (il vaudrait mieux éviter de le faire toutes les 5 minutes ou aux heures de pointe). Et il y a éventuellement des moyens qui permettent de basculer sur un serveur relais pour assurer la continuité du service (mais ça implique beaucoup de choses).

coupure du site pendant le rechargement de apache, temps de chargement de plus en plus plus long en fonction du nombre de Vhost disponible du serveur apache ... ?? ou alors ca n'a quasi pas d'influence sur le fonctionnement du serveur et dans ce cas, là solution que j'utilise actuellement deviendrai totalement inutile .

Apache utilise une table de hachage donc, théoriquement, en accès (association requête => VH) c'est rapide et leur nombre n'a que très peu d'influence. Au niveau du parsing des fichiers de configuration (réalisé au (re)démarrage ; tout est conservé en mémoire ensuite), ce sera légèrement plus long mais pas "exponentiel", enfin, tant que les VH, au niveau de leur déclaration, ne demande pas de résolution DNS.

[kanaziwok]

J'ai créé un fichier vhost de 1000 VirtualHost et tester de faire un "reload" et c'est vraiment instantanné.
Donc je pense que je vais adopter cette méthode pour les différents sites créés.

J'ouvrirai d'ici peu un sujet pour regler la sécurité du serveur :
J'ai testé avec PhpSecInfo et j'ai 50% warning et 50% OK .

Bref, je ne pense pas avoir d'autre question pour le titre du sujet bien qu'il est un peu dérivé.

En tout cas un grand merci à votre équipe, vous faites vraiment du bon boulot à tous les niveaux.