Merci de toutes ces réponses, j’épluche ça cet AM car il pleut, donc pas de travail dehors aujourd’hui.
L’appartenance à www-data, je le savais aussi mais de mémoire, chez moi, c’est root:www-data
[quote=“AnatomicJC”]Je suppose que tu as dézippé en tant que root ricardo.
Il faut que tes fichiers dropcenter appartiennent à l’utilisateur d’Apache: www-data
Donc:
chown -R www-data:www-data /ton/repertoire/web/drop-center
De manière générale, il faut regarder les logs, ricardo. Dans le cas de drop-center, si les fichiers n’appartiennent pas à www-data, tu as une belle erreur dans les logs d’erreur Apache.
[quote=“ricardo”]Encore autre chose et je ne sais pas comment accepter un certif en ligne de commande :
Code:
ERREUR : le certificat de «github.com» n’est pas digne de confiance.
ERREUR : le certificat «github.com» n’est pas d’un émetteur connu.
Vérif : dossier créé mais vide, évidemment.[/quote]
Pour cette erreur, il faut installer le paquet ca-certificates.[/quote]
En effet, je n’avais mis que root:www-data, qui jusuq’à maintenant suffisait à faire fonctionner tous mes serveurs.
J’ai donc modifié le dossier en [mono]www-data:www-data[/mono] et j’ai eu aussitôt la page d’installation du mot de passe, etc.
Me reste plus qu’à étudier les différents configs et à faire quelques essais avec ce serveur interne.
S’ils s’avèrent positifs, je l’installerai sur mon serveur externe.
Merci encore à tous de votre aide.
Je garde sous le coude tous les conseils qui y sont dispensés.
Je ne vois pas en quoi donner les fichiers à l’utilisateur www-data est une faille de sécurité.
www-data est l’utilisateur de base d’Apache et tous les fichiers qui vont être uploadés par ricardo au travers de cette application drop-center appartiendront à cet utilisateur www-data.
Je vois bien le principe d’une faille dans une appli web qui irait supprimer tous les fichiers appartenant à l’utilisateur www-data.
Pour ma part, il ne me viendrait pas à l’idée de sécuriser mon serveur en donnant tous les fichiers web à root, mais plutôt en séparant mes applis web par des utilisateurs différents, et l’utilisation d’un open_basedir pour commencer s’il s’agit d’une appli PHP.
Quant à mettre les dossiers en chmod 777, ça donne le droit à tous les utilisateurs du système, et pas uniquement www-data, à supprimer purement et simplement le dossier.
Je comprends bien fran.b que l’exemple que tu donnes est pour un utilisateur qui n’a pas les droits root.
Mais ricardo est root sur son serveur, pourquoi faire compliqué quand on peut faire simple ?
J’y ai passé un bon bout de temps pour comprendre le principe de leur “glissé le fichier”, mais j’y suis arrivé quand même 
Par contre, au niveau de la config, il n’y a pas grand chose comme choix, pour ne pas dire rien.
La principale modif qui m’intéressait c’est la taille maxi par fichier qui est de 2 Mo, ce qui va à peu près pour une photo ou un gros fichier texte mais une video de 2 Mo, c’est vite regardé 
.
En fouillant un peu, j’ai compris que ça se paramétrait dans le php5 du serveur.
J’ai modifié cette taille à 20 Mo qui devrait convenir à une petite video.
Toutefois, je voudrais avoir votre avis sur les inconvénients que ça pourrait apporter, sachant que ça ne sera ouvert qu’à un seul utilisateur à la fois. Ma question ne concerne pas la bande passante, même si je sais que ça pompe.
Cette config se fait dans le php5.ini de apache2 du serveur et non directement dans Dropcenter. Y-a-t-il un “danger” quelconque à augmenter cette possibilité d’upload ?
Merci
[quote=“AnatomicJC”]Je ne vois pas en quoi donner les fichiers à l’utilisateur www-data est une faille de sécurité.
www-data est l’utilisateur de base d’Apache et tous les fichiers qui vont être uploadés par ricardo au travers de cette application drop-center appartiendront à cet utilisateur www-data.
[…]
Je comprends bien fran.b que l’exemple que tu donnes est pour un utilisateur qui n’a pas les droits root.
[/quote]
Alors dans l’ordre
-
La plupart pour ne pas dire toutes les attaques que j’ai vues sur des serveurs WEB avaient comme but de modifier un php existant, d’en introduire un nouveau ou bien d’éxécuter un script (note que je vois mal ce qu’on peut faire d’autre, cette introduction est idiote). Si /var/www appartient à alfred avec autorisation de lecture et de parcours des répertoires à www-data, et que les fichiers sous /tmp ne peuvent être éxécuté (option noexec au montage), le serveur fonctionnera sans problème mais une attaque sera quasi impossible. Je suis cette règle sur les serveurs sensibles.
-
J’ai donné l’exemple pour montrer que dropcenter pouvait être installé sur unr machine où on peut accéder à ses fichiers via le web mais où on n’a aucun droit particulier. Même si on ne peut être www-data, on peut tout à fait installer dropcenter.
-
Ricardo: Tu as d’une part le fichier de configuration du dropcenter, d’autre part le php5.ini. Le danger réside juste dans la possibilité de saturer le disque en cours
Ok, merci des précisions fran.b 
[quote=“AnatomicJC”]Je ne vois pas en quoi donner les fichiers à l’utilisateur www-data est une faille de sécurité.
Je vois bien le principe d’une faille dans une appli web qui irait supprimer tous les fichiers appartenant à l’utilisateur www-data.
[/quote]
donc tu vois bien 
[quote=“fran.b”]…
- Ricardo: Tu as d’une part le fichier de configuration du dropcenter, d’autre part le php5.ini. Le danger réside juste dans la possibilité de saturer le disque en cours[/quote]
Où se trouve-t-il ?
J’ai cherché partout mais pas trouvé.
La page web de config ne permet rien ou presque.
Ptet un question de version car dans le screenshot du site, il y a des différences avec ce que j’ai.
C’est justement parce que je n’ai rien trouvé que j’ai fouillé dans les fichiers pour arriver à la solution indiquée dans header.php.
Dans etc/config.php, tu as une série de variables à définir assez simples.
Pas dans /etc chez moi, mais dans /php :
/var/www/dropcenter-master/php/config.php
En effet, il ya les différentes config mais pour ce qui est du poids maxi des fichiers, il faut quand même repasser par la config du serveur.
[mono]define(‘MAX_SIZE’,1000);//Taille maximale authorisée par fichier en Mo
(Pensez a configurer post_max_size et upload_max_size dans le fichier php.ini de votre serveur si vous voulez uploader de gros fichiers).[/mono]
Oups, tu as raison, php, pas etc. la taille du fichier se définit dans config.php et doit être compatible avec la valeur donnée dans le php.ini.
Oui, c’est bien ça, il faut modifier les deux ou seulement le .ini si la conf de Dropcenter est à 1000 mo en natif, comme chez moi.
J’ai fini tous mes tests et ça semble intéressant.
D’après ce que j’ai vu, on peut voir en “streaming” jusqu’à env .40 ou 50 mo (mon test qui passe est de 34).
Ensuite, pour du plus gros, on n’a plus que le choix du téléchargement, ce qui semble logique.
Encore une chose à vérifier, certainement pas avant demain et j’essaierai d’installer sur mon serveur fonctionnel pour des tests de temps de téléchargement d’un fichier de ~ 400 Mo, qui représente une video compressée H254 de > 1H.
@ François :
les nouveaux utilisateurs sont à créer par l’admin ou ce sont eux qui le font et qui doivent attendre la confirmation de l’admin ?
C’est toi qui crée l’utilisateur (du moins j’ai fait comme ça, après tu peux donner des droits aux utilisateurs)
Merci.
Ces droits, en dehors de ceux qui sont possibles à l’inscription, se configurent dans quel fichier ?
[quote=“fran.b”]…
Si /var/www appartient à alfred avec autorisation de lecture et de parcours des répertoires à www-data, et que les fichiers sous /tmp ne peuvent être éxécuté (option noexec au montage), le serveur fonctionnera sans problème mais une attaque sera quasi impossible. …[/quote]
Je reviendrai ensuite sur l’appartenance des fichiers mais j’ai besoin d’explication concrète sur ce qui est en gras.
Je suppose qu’il s’agit d’une ligne à ajouter dans le fstab ?
Si oui, laquelle exactement 
Le répertoire /tmp est un répertoire où tout le monde peut écrire. Donc si une personne malveillante, hostile et sournoise, dépose un fichier, l’idée est que ce fichier ne doit pas être exécuté. Cela est possible avec l’option noexec de mount si /tmp est sur une partition séparé ou est un tmpfs.
Mais rassure toi, je ne pratique pas tous ces judicieux conseils, par exemple mon répertoire /tmp est sur certaines de mes machines sur la partition racine…
[quote=“fran.b”]Le répertoire /tmp est un répertoire où tout le monde peut écrire. Donc si une personne malveillante, hostile et sournoise, dépose un fichier, l’idée est que ce fichier ne doit pas être exécuté. Cela est possible avec l’option noexec de mount si /tmp est sur une partition séparé ou est un tmpfs.
Mais rassure toi, je ne pratique pas tous ces judicieux conseils, par exemple mon répertoire /tmp est sur certaines de mes machines sur la partition racine.…[/quote]
Ça a toujours été le cas chez moi et je ne me souviens pas avoir lu qu’il fallait placer /tmp sur une partoche séparée 
Est-ce possible a posteriori de jouer avec les droits de ce répertoire ?
EDIT :
drwxrwxrwt - root:root
A noter qu’il y a des situations où le contenu de /tmp doit pouvoir être exécutable. Apparemment c’est le cas de debconf lors de l’installation de certains paquets si on n’a pas spécifié de répertoire alternatif dans la configuration d’APT (APT::ExtractTemplates::TempDir).
Richard: tu peux monter un système de fichiers a posteriori. Mais encore une fois, ça n’est pas très grave non plus.
Pascal: Bizarre ça, c’est une erreur de conception ou de paramétrage par défaut je trouve.
Vu et Vu.
François, d’après ce que tu préconise plus haut comme proprio et groupe pour /var/www, pourrais-tu me dire concrètement ce que je dois faire pour
/var = inchangé, je suppose = root:root
Mais pour
/var/www/ et tous les dossiers/fichiers qui suivent
actuellement pour tous ces derniers, j’ai : root:www-data
Que dois-je mettre : ricardo:www-data