Je ne veux pas autoriser les autres à accéder en lecture, j'ai donc ajouté mon utilisateur et le apache utilisateur à un groupe appelé apachme puis définissez ce groupe sur tous les fichiers et dossiers que je veux apache auxquels avoir accès, y compris la racine de la page Web. J'ai ensuite donné au groupe et au propriétaire toutes les autorisations. Après cela, apache ne peut toujours pas accéder aux fichiers sans définir l'autorisation de lecture pour autoriser tous (rwxrwxr--(0774) ).
Le dossier qui contient le fichier d'index, il appartient à apache avec le groupe apachme et les autorisations rwxrwxr-x(0775)
avec cela, j'obtiens une erreur 500, en la changeant en 0774 le laissera bien fonctionner
Ceux-ci étaient juste pour confirmer sous quel utilisateur apache s'exécutait et qu'il avait été ajouté au groupe.
Réponse acceptée :
Du point de vue de la sécurité, ce n'est pas vraiment une bonne idée de configurer des pages Web avec le même utilisateur d'Apache. L'utilisateur Apache doit pouvoir lire les pages Web, mais pas y écrire.
Ainsi, dans la configuration standard, il est normal que les structures web soient lisibles par tous, et lorsqu'il y a un besoin d'écriture, normalement accessibles en écriture par l'utilisateur Apache, ce qui est un cauchemar pour la sécurité.
L'une des stratégies pour éviter cela consiste à installer/utiliser mod_ruid2. https://github.com/mind04/mod-ruid2
Quant à Debian, il suffit de faire :
apt-get install libapache2-mod-ruid2
Veuillez noter que l'utilisateur par défaut d'Apache varie selon la distribution. Dans Debian, c'est www-data, dans RH/CentOS c'est apache, et dans SuSE, wwwrun. Je l'appellerai désormais l'utilisateur par défaut d'Apache.
Si vous ne définissez aucune directive dans un vhost, il se comportera de manière traditionnelle; sinon le comportement sera modifié.
L'idée est d'avoir un processus en cours d'exécution dans le vhost avec l'utilisateur qui a des droits sur le vhost, et en tant que tel, les fichiers auront cette propriété, et comme vous le souhaitez, les autres utilisateurs ne pourront pas les lire. Normalement, vous définissez un utilisateur par vhost.
Dans les directives Virtualhost ou Directory d'un vhost, vous définissez l'utilisateur et le groupe qui seront actifs pour ce répertoire. L'utilisateur :groupe d'utilisateurs est ce que seront les autorisations effectives qu'Apache utilisera lors de l'accès à l'hôte virtuel/répertoire, et en tant que tel, tout utilisateur appartenant à ce groupe pourra écrire/voir les répertoires.
<Directory "/vhostdir/">
RMode config
RUidGid user usergroup
....
Ainsi, lors de l'écriture des répertoires, les fichiers peuvent désormais être créés en tant que 660 avec la propriété de user:usergroup s'ils sont gérés par un groupe d'utilisateurs. De même, les fichiers peuvent également être créés par un autre utilisateur avec des autorisations de lecture pour le monde ; cependant pour l'écriture, ce ne sera pas l'utilisateur par défaut d'Apache, mais plutôt cet autre utilisateur.
Les avantages de mod_ruid2 sont alors :
- dans un environnement d'hébergement virtuel, les utilisateurs ne peuvent pas lire les fichiers des autres utilisateurs ;
- dans un seul utilisateur, vous pouvez toujours créer des fichiers en tant qu'autre utilisateur, et ni l'utilisateur par défaut d'Apache, ni l'utilisateur ruid2 ne pourront les écraser
- plus important encore, l'écriture des fichiers se fera désormais avec l'utilisateur ruid2, et non plus globalement avec l'utilisateur par défaut d'Apache.
Depuis la page github :
À PROPOS mod_ruid2 est un module suexec pour apache 2.0, 2.2 et 2.4, basé
sur mod_ruid et mod_suid2-il ne fonctionne que sur Linux car seul le noyau Linux a implémenté les capacités de processus requises.
-il a de meilleures performances que mod_suid2 car il n'a pas besoin de tuer les enfants httpd après une requête. il utilise les capacités du noyau
et après avoir reçu une nouvelle requête suids à nouveau.
-il y a quelques problèmes de sécurité, par exemple si l'attaquant exploite avec succès le processus httpd, il peut définir des capacités efficaces et
setuid à la racine. je recommande d'utiliser un correctif de sécurité dans le noyau
(grsec), ou quelque chose..-il y a deux modes de fonctionnement principaux :stat et config
1. config est par défaut, vous devez définir uid et gid. Si aucun [ug]id n'est défini, l'utilisateur et le groupe par défaut sont utilisés.
- stat httpd setuid et setgid à uid et gid du nom de fichier (script)/répertoire demandé c'est bon si vous utilisez mod_vhost_alias
pour l'hébergement virtuelINSTALLER
1. téléchargez et installez la dernière version de libcap à partir d'ici
2. exécutez /apachedir/bin/apxs -a -i -l cap -c mod_ruid2.c
3. configurez httpd.conf
4. redémarrez apacheOPTIONS DE CONFIGURATION :RMode config|stat (la valeur par défaut est config) RUidGid
user|#uid group|#gid – lorsque RMode est configuré, définissez cet uid et ce gidRMinUidGid user|#uid group|#gid – lorsque uid/gid est <à min uid/gid
défini sur l'uid/gid par défaut RDefaultUidGid user|#uid group|#gidRGroups group1 group2 – groupes supplémentaires définis via setgroups @none –
efface tous les groupes définis précédemment.RDocumentChrRoot - Définissez le répertoire chroot et la racine du document à l'intérieur
EXEMPLE :
<VirtualHost example.com> ServerAdmin [email protected] RDocumentChRoot /home /example.com/public_html ServerName example.com ServerAlias www.example.com RMode config # unnecessary since config is the default RUidGid user1 group1 RGroups apachetmp <Directory /home/example.com/public_html/dir> RMode stat </Directory> <Directory /home/example.com/public_html/dir/test> RMode config RUidGid user2 group2 RGroups groups1 </Directory> <Directory /home/example.com/public_html/dir/test/123> RUidGid user3 group3 </Directory> <Location /yustadir> RMode config RUidGid user4 user4 RGroups groups4 </Location>