[Problème] En admin, bloquer l'accès aux dossiers des autres sites du serveur

[django29]

Bonjour
Je viens de constater que certains composants permettent l'accès en admin à tous les fichiers de tous les autres sites sur le même serveur ! Dans le cas présent (et sur tous mes sites utilisant RSForm), un bouton de recherche de fichier à joindre à un email explore tous les dossiers de tous les sites.
Quelqu'un aurait une solution pour limiter la recherche de fichiers au site sur lequel on travaille, ou mieux, à un dossier précis (/images par ex.) ?

[Wismer]

Salut

Dans la conf de ton serveur apache, il faut rajouter dans ton virtual host, la ligne suivante

php_admin_value open_basedir "/var/www/html/***********/www/:/tmp:/usr/share/php/:/usr/share/pear/" 

Apache limite l'acces uniquement aux repertoires indiqués dans le open_basedir. ( c'est a ajuster selon tes besoins )

++
Wis

PS : La regle peut changer en fonction de la version du Apache
PS2 : Ce n'est pas la bonne regle si tu veux limiter l'acces a un repertoire, cette regle encapsule le site dans son espace et rien ne sort. Pour limiter a un repertoire, c'est autre chose.

[django29]

Réponse de l'hébergeur (O2switch) :

Cela ne sera pas possible ni modifiable dans un contexte d'hébergement mutualisé. C'est bien au niveau code du site que se gèrent ces limitations.

[RobertG]

Bonjour,

Par quelle fonction de RSForm as-tu accès à des fichiers sur le serveur ?

[fabrice4821]

Bonjour,

Il y a le même problème avec le composant Profiles.
Si vous avez une solution, je suis également preneur

[django29]

Le PB est à : RSForm/Gestion des formulaires/Nom du formulaire/Propriétés/Courriel de l'utilisateur/Joindre un fichier(oui)/Sélectionner le fichier du serveur.

[RobertG]

Il faudrait poser la question aux auteurs. J'ai eu beau chercher un paramétrage, je n'en ai pas trouvé.

[cavo789]

Sur le plan strict php, cela me semble normal. Tu as donc un hébergement sur lequel tu as créé plusieurs sites sous public_html (ou équivalent).

Tout cela avec le même utilisateur Unix. Ton utilisateur (disons www_root) est celui qui est utilisé pour accéder aux fichiers disponibles sous public_html.

Ce que tu décris est donc logique dans ce schéma.

Une excellente réponse t'a été donnée plus haut en mentionnant la restriction openbase_dir. Une précision toutefois : certains hébergées autorisent de créer un fichier php.ini à la racine de chacun de tes sites. À voir si ton hébergeur le fait. Si oui, tu as ta solution : créé un php.ini avec la clause openbase_dir qui limite ce site là à son root 3t au dossier /tmp. Et cela pour chacun de tes sites.

[django29]

• J'ai essayé openbase-dir dans .htaccess: blocage immédiat du site. (Je suis pourtant sûr du chemin).
• La plupart de mes dossiers sites ne sont pas dans public_html, mais au même niveau que ce dossier. Et même pb pour ceux qui sont dans public_html.
• RSJoomla me dit qu'il ne peuvent pas régler ce pb, mais ils me proposent simplement un override du template pour dépublier le bouton de recherche de fichier. Du sparadrad sur une jambe de bois.

[roland_d_alsace]

Oui, dangereux de jouer sur cette variable d'environnement php (open_basedir et pas openbase-dir), car les "include", "require", etc... l'utilisent aussi, donc ton code PHP ne fonctionnera plus.

Si tu actives l'affichage des erreurs tu dois avoir de paquets d'erreur du type :
PHP Fatal error: require_once(): Failed opening...
PHP Warning: require_once(): open_basedir restriction in effect....
...

[cavo789]

open_basedir et pas openbase-dir

A chaque fois j'hésite et le pire c'est que mon correcteur orthographique (sur mon smartphone) me propose les deux.

Dangereux; oui et non... Il faut vraiment bien tester, comme quand on joue avec les CORS.

Dans l'absolu, aucun script d'un site ne devrait jamais remonter plus haut que lui-même aussi les require(), include() et autres ne devraient pas poser de problème.

Si l'hébergeur permet de placer un fichier php.ini à la racine du site; cette piste pourrait fonctionner. Mais, oui une fois encore, tester, tester, tester.


Pour ce qui concerne RSJoomla (ou autre), ce n'est donc pas un problème de programmation mais un souci parce que tu héberges de multiples sites sur le même hébergeur avec le même compte. C'est un problème à ton niveau; pas au niveau de PHP.

RSJoomla pourrait programmer quelque chose, un contrôle, mais cela ne serait valable que pour ce script-là et pas un autre. Cela répondrait à ta question, pour ce formulaire d'upload mais ce serait une sécurité "sparadrap" vu que tu vas te croire en sécurité mais c'est un sentiment faux. N'importe quel autre script sur ton site, qui n'aurait pas cette protection (en fait, tous les scripts) pourront quand même monter plus haut.

La solution open_basedir est la plus propre... pour autant qu'elle soit possible.

Tu pourrais aussi voir si tu peux créer de multiples comptes utilisateurs; au niveau de ton hébergeur et du coup voir si tu peux créer un compte utilisateur site_1 qui n'aurait accès qu'au site 1. Mais pas sûr que ton hébergeur te propose cela.

[django29]

Réponse de RSJoomla :
This file accessibility is simply based on your own server basically what PHP can access. If RSForm!Pro can do this (which is actually PHP that does this), then your websites are normally accessible between them - this isn't something you can control from RSForm!Pro nor related to.

Other components you're mentioning have been designed to simply not exit your Joomla! JPATH_SITE, however this doesn't actually limit anything on your website. RSForm!Pro simply allows what your server allows to have increased flexibility and select any available file from your server.
If you want to limit this accessibility, then you can try using the open_basedir directive accordingly for your installations (you can ask your hosting for details on how you can set this up) - this is used to limit the files that can be accessed by PHP to the specified directory-tree.

[modo]
En Français ça donne :
Cette accessibilité aux fichiers est simplement basée sur votre propre serveur, ce à quoi PHP peut accéder. Si RSForm!Pro peut le faire (en fait c'est PHP qui le fait), alors vos sites Web sont normalement accessibles entre eux - ce n'est pas quelque chose que vous pouvez contrôler à partir de RSForm!Pro.

Les autres composants que vous mentionnez ont été conçus pour simplement ne pas quitter votre Joomla! JPATH_SITE, mais cela ne limite en fait rien sur votre site Web. RSForm!Pro permet simplement à ce que votre serveur permet d'avoir une flexibilité accrue et puisse sélectionner n'importe quel fichier disponible à partir de votre serveur.
Si vous souhaitez limiter cette accessibilité, vous pouvez essayer d'utiliser la directive open_basedir pour vos installations (vous pouvez demander à votre hébergement des détails sur la façon dont vous pouvez configurer cela) - cela est utilisé pour limiter les fichiers accessibles par PHP à l'arborescence de répertoires spécifiée.
[/modo]

[RobertG]

Bonjour,

Le code d'un composant ne peut-il pas limiter la remontée dans l'arborescence ?
Si je me souviens bien, il m'est arrivé (avec Akeeba backup peut-être ?) d'avoir une alerte du type "attention, le dossier ne sera peut-être pas utilisable" en passant à un répertoire au-dessus de celui du site, ce qui veut donc bien dire que le script peut faire la comparaison et pourrait donc interdire l'accès, non ?

A une époque, sur mon serveur Premium PHPNET, j'avais la possibilité de bloquer site par site l'open_basedir pour interdire l'accès à d'autres dossiers et de préciser, pour le stockage des sauvegardes, le dossier autorisé hors de celui du site. Je ne retrouve plus ça dans la nouvelle interface Nuxit.

[roland_d_alsace]

Dans l'absolu, aucun script d'un site ne devrait jamais remonter plus haut que lui-même aussi les require(), include() et autres ne devraient pas poser de problème.

En ce sens tu as effectivement raison cavo789 , j'avais trop interprété et je croyais que django29 voulait accéder à un dossier spécifique de son site (type "documents", donc hors framework et code, comme c'est généralement le cas).

Dans tous les cas il faut bien tester les effets d'une modification de ce type de variable, et donc avoir quelques notions de config apache et de programmation.

Pour ma part j'avais des frameworks communs à tous mes vhosts et je jouais donc sur les open_basedir, set_include_path,... globaux.
Mais j'ai un peu laissé tomber les configurations "non conventionnelles" qui me posaient souvent problème lors de changement de serveur et d'OS serveur.

[django29]

Je tourne en rond :
Dernière réponse de O2switch : " Pour moi, vous ne pourrez pas limiter côté php.ini ou côté cPanel/serveur, c'est au niveau du code que vous devez faire vos changements. "
Dernière réponse de RSJoomla : " Pour limiter l'accessibilité au dossier du site, vous devez utiliser open_basdir - demandez la procédure à votre hébergeur"

Bon, ben voilà .....