Bonjour à tous,

J'aimerais lancer un débat sur la problématique suivante:

Soit un serveur, dédié, sous linux, hébergeant quelques sites distincts
(allez, de 5 à 20).
Soit les besoins suivants pour les différents sites:
- php, et notamment écriture de fichiers par php
- acces ftp pour les utilisateurs
Et soit les besoins subsidiaires suivants pour l'ensemble du serveur
- sécurité des données utilisateurs
- nécessité que les gens ne puissent pas, soit par ftp (facile), soit par
ftp (plus dur, sans le brider), accéder aux données des autres.
- sécurité du serveur en tant que tel

Je me demande quelle est la meilleure solution, sachant que, de toute celles
que j'ai essayées jusqu'a présent, je n'en ai trouvé aucune qui me
satisfasse complétement. Les solutions testées jusqu'a présent:

- apache 2, avec des vhosts et php en tant que module. Un user par site,
avec donc un répertoire dédiés. tous les répertoires se trouvant dans /home
(apache:apache, 750). le repertoire de www.domaine1.com appartenant a
domaine1:apache, en 770. Solution très stable, éprouvée, mais posant le
problème suivant : les droits... le 770 m'est obligé, pour que
l'utilisateur domaine1 puisse a la fois écrire des fichiers par ftp, et
pour que php (apache, quoi) puisse également écrire sur ces fichiers. Cela
implique que les utilisateurs sont tous dans le même groupe, et peuvent
donc potentiellement se balader dans les répertoires des autres (enfin..
après c'est une histoire de config ftp et php, mais potentiellement c'est
possible). De plus, si la personne décide de placer ces fichiers inscrit en
ftp en 700, apache ne peut pas les lire... dommage.

- apache 2, avec suexec et php en tant que cgi. Une solution que je n'ai
jamais vraiment bien réussi à mettre en place. la config doit être super
nickel, ne tolère aucune approximation, et qui plus est n'est que
partiellement stable. (enfin c'est ce que j'en retiens.) de plus, ça pose
le problème de php en tant que cgi, d'imposer le safe_mode, voire de
désactiver certaines fonctions. Cela dit, si certains fonctionnent comme
ça, je veux bien le savoir: j'essayerais de creuser un peu plus dans la
solution qui me semble pour l'instant la meilleure

- apache 1.3.x, avec suexec et php en tant que cgi : parait-il que ça
fonctionne beaucoup mieux, notamment en mode multi-thread. si c'est vrai,
merci de me le confirmer. Mes réticences étant :
- la nécessité du coup d'installer apache 1.3.x ET apache 2.0.x (puisque
j'utilise également d'autres services, genre webdav et openssl, qui ne
fonctionne semble t'il que avec apache 2 (notament pour un serveur
subversion)
- d'utiliser une version antérieure d'apache, sachant que apache 2.0.x est
qd même assez vieux, je n'arrive pas à comprendre pourquoi diable n'ont
t'il pas, chez apache, trouvé le moyen de faire au moins aussi bien.


voili voilou... vos réactions svp
Lascap

Le Sun, 09 Oct 2005 15:31:53 +0200, Lascap a écrit :
> Cela
> implique que les utilisateurs sont tous dans le même groupe, et peuvent
> donc potentiellement se balader dans les répertoires des autres (enfin..
> après c'est une histoire de config ftp et php, mais potentiellement c'est

Tout serveur ftp digne de ce nom permet un chroot dans le répertoire de
l'utilisateur.

> - la nécessité du coup d'installer apache 1.3.x ET apache 2.0.x (puisque
> j'utilise également d'autres services, genre webdav et openssl, qui ne
> fonctionne semble t'il que avec apache 2 (notament pour un serveur
> subversion)

On peut faire du HTTPS et du webdav avec Apache 1.3 sans problèmes.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Patrick Mevzek wrote:


> Tout serveur ftp digne de ce nom permet un chroot dans le répertoire de
> l'utilisateur.


Par chroot tu entend que la racine du serveur, du point de vue du type est
son home à lui ? on est d'accord. Mais a vrai dire le ftp ne me semble pas
être le pb le plus insurmontable.


> On peut faire du HTTPS et du webdav avec Apache 1.3 sans problèmes.

vrai ? pourtant j'ai cru comprendre que subversion fonctionnait, dans son
mode webdav, avec un serveur apache 2.0.x exclusivement.

Ceci dit, si vraiment il s'avère que un apache 1.3.x me permet de résoudre
de manière satisfaisante mon problème, pourquoi pas même installer les
deux, le apache 2 pour le https et le 1.3 pour le reste. Mais voilà, un
apache 1.3 avec un php en cgi est-il une solution stable, performante, et
surtout satisfaisante du point de vue de la sécurité?

Le Mon, 10 Oct 2005 00:01:48 +0200, Lascap a écrit :
>> Tout serveur ftp digne de ce nom permet un chroot dans le répertoire de
>> l'utilisateur.
>
>
> Par chroot tu entend que la racine du serveur, du point de vue du type est
> son home à lui ?

Oui, quand l'utilisateur se connecte via FTP, sa racine de laquelle il ne
pourra jamais sortir est en fait son $HOME sur le serveur, donc une partie
de la vraie racine. Ainsi l'utilisateur ne peut rien faire en dehors de
son home.

>> On peut faire du HTTPS et du webdav avec Apache 1.3 sans problèmes.
>
> vrai ?

Oui, puisque je le fais.

> pourtant j'ai cru comprendre que subversion fonctionnait, dans son
> mode webdav, avec un serveur apache 2.0.x exclusivement.

Pour subversion, je ne sais pas.
Voir dans la doc du logiciel ses prérequis.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Le Mon, 10 Oct 2005 03:23:49 +0200, Lascap a écrit :
>> Oui, puisque je le fais.
>
> Ok, je te crois sur parole. cependant, le https n'est qu'une option
> subsidiaire : mon vrai besoin c'est des vhosts en suexec, de manière à ce
> que les process tournant pour ce vhost donné appartiennent bien à
> l'utilisateur domaine1, domaine2, etc... C'est également ce que tu fais?

Non, pas personnellement, mais on peut faire des vhosts en suexec avec
Apache 1.3, la doc est formelle.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>