Pourquoi ne puis-je pas supprimer quelque chose même si je dispose d'autorisations 777 de test?
Celui-ci me dérange. Je devais réinstaller mon installation Joomla . Ce qui est bien puisque je le fais pour la pratique dans un effort pour apprendre Joomla et Linux (CentOSv7).
J'ai déjà eu des problèmes avec les autorisations de fichiers et la propriété qui ont été résolus avec la lecture des journaux d'erreurs et les tests avec les autorisations 777 pour vérifier les utilisateurs en cours d'exécution. Le problème est ce temps qui ne fonctionne pas?
Si tout le monde avait la permission sur le dossier images, par exemple, je pense pouvoir effacer n'importe quoi sans problème.
Voici ce que je reçois de la page d'administration lorsque j'essaie de créer un dossier à la racine des images (avec 777 perms pour les tests)
JFolder::create: Could not create folder. Path: /srv/dpca/www/images/test
Je suis sur un hébergeur dédié exécutant Nginx avec PHP v5.5. Joomla ne semble pas être en mesure d'écrire des journaux et les erreurs conduisent à des publications sur les droits de propriété et les autorisations d'accès aux fichiers. mais je pense avoir un problème différent.
J'essaie de supprimer une image avec les autorisations 666 qui lui sont attribuées et elle échoue et réussit? Ne supprime toujours pas cependant.
Complétez les informations si cela permet d’assurer ma position. Autorisations du répertoire racine (Remarque: je teste 777 uniquement sur les images):
drwxr-xr-x. 10 nginx nginx 4096 Dec 24 13:51 administrator
drwxr-xr-x. 2 nginx nginx 42 Dec 24 13:51 bin
drwxr-xr-x. 2 nginx nginx 6 Jan 12 20:48 cache
drwxr-xr-x. 2 nginx nginx 4096 Dec 24 13:51 cli
drwxr-xr-x. 16 nginx nginx 4096 Dec 24 13:51 components
-r--r-----. 1 nginx nginx 1885 Jan 12 20:07 configuration.php
-rw-r--r--. 1 nginx nginx 2915 Dec 24 13:51 htaccess.txt
drwxrwxrwx. 5 nginx nginx 4096 Jan 11 21:04 images
drwxr-xr-x. 2 nginx nginx 61 Dec 24 13:51 includes
-rw-r--r--. 1 nginx nginx 140 Jan 10 22:03 index.html
-rw-r--r--. 1 nginx nginx 1212 Dec 24 13:51 index.php
-rw-r--r--. 1 nginx nginx 1873 Dec 24 13:53 joomla.xml
drwxr-xr-x. 2 nginx nginx 6 Jan 10 22:09 jrt
drwxr-xr-x. 4 nginx nginx 51 Dec 24 13:51 language
drwxr-xr-x. 5 nginx nginx 66 Dec 24 13:51 layouts
drwxr-xr-x. 11 nginx nginx 4096 Dec 24 13:51 libraries
-rw-r--r--. 1 nginx nginx 18092 Dec 24 13:51 LICENSE.txt
drwxr-xr-x. 2 nginx nginx 23 Dec 24 13:51 logs
drwxr-xr-x. 18 nginx nginx 4096 Dec 24 13:51 media
drwxr-xr-x. 27 nginx nginx 4096 Dec 24 13:51 modules
drwxr-xr-x. 14 nginx nginx 4096 Dec 24 13:51 plugins
-rw-r--r--. 1 nginx nginx 4213 Dec 24 13:51 README.txt
-rw-r--r--. 1 nginx nginx 842 Dec 24 13:51 robots.txt.dist
drwxr-xr-x. 5 nginx nginx 64 Dec 24 13:51 templates
drwxr-xr-x. 2 nginx nginx 6 Jan 12 20:52 tmp
-rw-r--r--. 1 nginx nginx 1690 Dec 24 13:51 web.config.txt
Montrant que php-fpm et le serveur web fonctionnent sous le bon utilisateur:
nginx 64106 0.0 1.1 412288 20668 ? S Jan10 0:06 php-fpm: pool www
nginx 64107 0.0 1.0 412108 20260 ? S Jan10 0:06 php-fpm: pool www
nginx 64108 0.0 1.2 415252 23608 ? S Jan10 0:06 php-fpm: pool www
nginx 64109 0.0 1.2 414472 22780 ? S Jan10 0:05 php-fpm: pool www
nginx 64110 0.0 1.1 413048 21340 ? S Jan10 0:06 php-fpm: pool www
nginx 64250 0.0 1.0 411880 20276 ? S Jan10 0:06 php-fpm: pool www
nginx 99912 0.0 1.1 413276 21320 ? S 08:13 0:01 php-fpm: pool www
root 117112 0.0 0.0 47548 1184 ? Ss 20:49 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 117113 0.0 0.1 50144 2520 ? S 20:49 0:00 nginx: worker process
SELinux était mon problème. J'ai été capable d'écrire dans les répertoires une fois que je l'ai configuré en mode permissif.
Sudo setenforce 0
Cependant, je ne voulais pas le désactiver entièrement comme prévu pour corriger le problème. En suivant les étapes de CentOS sur SELinux , j’ai été en mesure de déterminer le contexte correct pour les dossiers/fichiers devant être inscriptibles. En mode permissif, j'ai ajouté une image via la page Administrateur.
Par défaut, les messages de journal SELinux sont écrits dans /var/log/audit/audit.log via le système d'audit Linux Audit, qui est démarré par défaut.
Le journal est un peu cryptique, vous pouvez donc exécuter quelque chose comme ceci qui donnera une réponse plus interprétative et même une action recommandée.
SELinux is preventing /usr/sbin/php-fpm from write access on the directory /srv/dpca/www/images.
***** Plugin httpd_write_content (92.2 confidence) suggests ***************
If you want to allow php-fpm to have write access on the images directory
Then you need to change the label on '/srv/dpca/www/images'
Do
# semanage fcontext -a -t httpd_sys_rw_content_t '/srv/dpca/www/images'
# restorecon -v '/srv/dpca/www/images'
A l'époque c'était le contexte des images (et de tous les autres dossiers)
drwxr-xr-x. nginx nginx unconfined_u:object_r:httpd_sys_content_t:s0 images
J'ai donc écrit un petit script qui lisait tous les dossiers accessibles en écriture conformément à Informations système> Autorisations des dossiers (à l'exception de configuration.php). Ce n’est pas un bon exemple de programmation, mais c’est essentiellement la répétition des commandes suivantes en cours d’exécution.
Sudo semanage fcontext -a -t httpd_sys_rw_content_t '/srv/dpca/www/{folder}'
Sudo restorecon -v '/srv/dpca/www/{folder}'
où le dossier a été remplacé pour chaque passe. Après quoi, j'ai remis SELinux en mode d’application avec Sudo setenforce 1.
Après avoir vérifié à nouveau les informations système> Autorisations des dossiers, mes dossiers sont désormais inscriptibles.
Le moyen le plus rapide de vérifier si votre installation de Joomla! Dispose de l’autorisation nécessaire est la fonction intégrée:
Il suffit d'aller dans Système-> Informations système-> Autorisations de dossier, ce qui devrait ressembler à ceci: 
Là, vous pouvez voir exactement s’il ya un problème avec vos autorisations, ou quelque chose d’autre.