Autorisation Apache 13 refusée dans le répertoire personnel de l'utilisateur
Le site Web de mon ami fonctionnait bien jusqu'à ce qu'il déplace la racine du document de /var/www/xxx à /home/user/xxx.
Apache donne 13 messages d'erreur d'autorisation refusée lorsque nous essayons d'accéder au site via un navigateur Web.
Le site est configuré comme un répertoire virtuel. Toutes les configurations Apache étaient inchangées (sauf pour le changement de répertoire).
Nous avons essayé de chmod 777 /home/user/xxx, chown Apache/home/user/xxx. Mais ils n'ont pas fonctionné.
Existe-t-il une sorte de fonction de sécurité définie dans les répertoires personnels de l'utilisateur? Le système d'exploitation du serveur est CentOS (Godaddy VPS).
Toute aide est appréciée!
Merci!
Il s'avère ... nous avons également dû chmod 755 le répertoire parent, l'utilisateur, en plus de xxx.
im utilisant CentOS 5.5 et pour moi c'était SElinux jouer avec, j'ai oublié de vérifier cela. vous pouvez le désactiver temporairement en faisant en tant que root
echo 0 > /selinux/enforce
j'espère que ça aide quelqu'un
selinux est la cause de ce problème .....
TException: Erreur: TSocket: Impossible de se connecter à localhost: 9160 (autorisation refusée [13]) Pour le résoudre, vous devez modifier une valeur booléenne SELinux (qui persistera automatiquement lors des redémarrages). Vous pouvez également redémarrer httpd pour réinitialiser le proxy pro, bien que cela ne soit pas strictement requis.
setsebool -P httpd_can_network_connect 1
ou
(13) Autorisation refusée
L'erreur 13 indique un problème d'autorisations du système de fichiers. Autrement dit, Apache s'est vu refuser l'accès à un fichier ou un répertoire en raison d'autorisations incorrectes. Cela n'implique généralement pas de problème dans les fichiers de configuration d'Apache.
Afin de servir des fichiers, Apache doit avoir l'autorisation appropriée accordée par le système d'exploitation pour accéder à ces fichiers. En particulier, l'utilisateur ou le groupe spécifié dans httpd.conf doit être capable de lire tous les fichiers qui seront servis et de rechercher le répertoire contenant ces fichiers, ainsi que tous les répertoires parents jusqu'à la racine du système de fichiers.
Les autorisations typiques sur un système de type Unix pour les ressources n'appartenant pas à l'utilisateur ou au groupe spécifié dans httpd.conf seraient 644 -rw-r - r-- pour les fichiers ordinaires et 755 drwxr-x-r-x pour les répertoires ou les scripts CGI. Vous devrez peut-être également vérifier les autorisations étendues (telles que les autorisations SELinux) sur les systèmes d'exploitation qui les prennent en charge.
Un exemple
Disons que vous avez reçu l'erreur Autorisation refusée lors de l'accès au fichier /usr/local/Apache2/htdocs/foo/bar.html sur un système de type Unix.
Vérifiez d'abord les autorisations existantes sur le fichier:
cd/usr/local/Apache2/htdocs/foo ls -l bar.htm
Réparez-les si nécessaire:
chmod 644 bar.html
Faites de même pour le répertoire et chaque répertoire parent (/ usr/local/Apache2/htdocs/foo,/usr/local/Apache2/htdocs,/usr/local/Apache2,/usr/local,/usr):
ls -la chmod + x. cd ..
répéter jusqu'à la racine
Sur certains systèmes, l'utilitaire namei peut être utilisé pour rechercher des problèmes d'autorisations en répertoriant les autorisations le long de chaque composant du chemin:
namei -m /usr/local/Apache2/htdocs/foo/bar.html
Si toutes les autorisations standard sont correctes et que vous obtenez toujours une erreur Autorisation refusée, vous devez vérifier les autorisations étendues. Par exemple, vous pouvez utiliser la commande setenforce 0 pour désactiver SELinux et vérifier si le problème disparaît. Si tel est le cas, ls -alZ peut être utilisé pour afficher l'autorisation SELinux et chcon pour les corriger.
Dans de rares cas, cela peut être dû à d'autres problèmes, tels qu'un problème d'autorisations de fichiers ailleurs dans votre fichier Apache2.conf. Par exemple, une directive WSGIScriptAlias ne mappant pas sur un fichier réel. Le message d'erreur peut ne pas être précis sur le fichier illisible.
NE PAS mettre des fichiers ou des répertoires en mode 777, même "juste pour tester", même si "c'est juste un serveur de test". Le but d'un serveur de test est de bien faire les choses dans un environnement sûr, et non de s'en tirer mal. Tout ce qu'il vous dira, c'est si le problème vient des fichiers qui existent réellement.
Je ne sais pas si vous l'avez résolu mais dans votre httpd.conf
Vérifiez pour voir vos paramètres d'utilisateur/groupe. Habituellement, il sera réglé sur
Utilisateur www Groupe www
Si c'est le cas, changez-le en votre nom/groupe
Utilisateur du groupe Greg
Le journal d'erreurs d'Apache expliquera pourquoi vous obtenez une autorisation refusée. En outre, serverfault.com est un meilleur forum pour une question comme celle-ci.
Si le journal des erreurs indique simplement "autorisation refusée", indiquez à l'utilisateur que le serveur Web s'exécute et essayez de lire le fichier en question. Ainsi, par exemple:
Sudo -s
su - nobody
cd /
cd /home
cd user
cd xxx
cat index.html
Vérifiez si l'un de ces messages vous donne l'erreur "autorisation refusée".
Vous ne pouvez pas définir le Loglevel dans httpd.conf pour déboguer? (J'utilise FreeBSD)
ee usr/local/etc/Apache22/httpd.conf
changer le niveau de journalisation:
'LogLevel: contrôle le nombre de messages enregistrés dans le journal des erreurs. Les valeurs possibles incluent: debug, info, notice, warn, error, crit, alert, Emerg. '
Essayez de passer au débogage et de revérifier le journal des erreurs après cela.
Cela pourrait être SELinux. Vérifiez le fichier journal approprié (/ var/log/messages? - cela fait un moment que je n'ai pas utilisé un dérivé de RedHat) pour voir si cela bloque l'accès.
Erreur:
[erreur] [client 127.0.0.1] (13) Autorisation refusée: impossible d'ouvrir le fichier de mot de passe: /home/XXX/svn/svn_password
Info:
## Étiquettes de fichiers de contexte de sécurité SELinux # Httpd_sys_content_t Type utilisé par les pages Web statiques régulières avec les extensions .html et .htm. # Httpd_sys_script_ro_t Requis pour que les scripts CGI lisent des fichiers et répertoires. # httpd_sys_script_ra_t Identique au type httpd_sys_script_ro_t mais permet également d'ajouter des données aux fichiers par le script CGI. # httpd_sys_script_rw_t Les fichiers de ce type peuvent être modifiés par un script CGI de quelque manière que ce soit, y compris la suppression . # httpd_sys_script_exec_t Le type requis pour l'exécution des scripts CGI
Solution:
[root @ localhost] # perror 13 Code d'erreur 13 du système d'exploitation: autorisation refusée [root @ localhost] # chown Apache.apache/home/XXX/svn/-R [root @ localhost] # semanage fcontext -a -t httpd_sys_script_rw_t "/home/XXX/svn(/.*)?""..____. deposited[root@localhost 3/# restorecon -R -v/home/XXX/svn/ [Root @ localhost] # restorecon reset/home/XXX/svn/context [Root @ localhost] # ls -dZ /home/XXX/svn/ drwxr-xr-x. Apache apache system_u: object_r: httpd_sys_rw_content_t: s0 /home/XXX/svn/[.____. diplomatiqueroot@localhost}# ls -dZ/home/XXX/svn/svn_password - rwxr-xr-x. Apache apache system_u: object_r: httpd_sys_rw_content_t: s0 /home/XXX/svn/svn_password[.____.ro_directedroot@localhost