Impossible d'accéder à l'annuaire dont je suis membre du groupe
Sur mon serveur Web, j’ai un répertoire ‘www’ qui a les droits drwxrwxr-- et l’utilisateur: groupe root:www-data afin qu’Apache puisse y accéder.
Maintenant, j'ai ajouté mon compte au groupe www-data avec
Sudo usermod -g www-data myuser
et si je le fais groups alors www-data en fait partie, mais lorsque j'essaie de me connecter simplement, je reçois le message ‘Permission denied’.
Si je change l’utilisateur en ‘myuser’ ou si je mets le groupe sur un autre groupe dont je suis membre, je peux entrer.
Est-ce que je manque quelque chose?
Votre processus a sa liste de groupes définie au moment de la connexion. Vous devez donc vous reconnecter pour que les modifications prennent effet.
Je suggérerais également que vous ajoutiez www-data comme groupe supplémentaire plutôt que comme groupe principal (qui est défini sur un groupe uniquement auquel vous appartenez. Vous devriez pouvoir le faire avec les commandes suivantes:
# Reset to your original primary group
Sudo usermod -g myuser myuser
# Add an extra supplementary group
Sudo usermod --append -G www-data group
Si vous voulez que les fichiers que vous créez soient lisibles par les autres membres du groupe www-data, ajustez votre umask en conséquence:
umask 002
Étant donné que votre groupe principal est un groupe personnel, cela ne devrait pas affecter la sécurité des fichiers que vous créez.
Il est également intéressant de définir le bit setgid sur les répertoires dans lesquels vous allez créer les fichiers: les fichiers hériteront de la propriété du groupe sur le répertoire parent:
chmod g+s www/
Pour moi, c'était une chose différente qui a entraîné cette erreur
même nom d'utilisateur avec deux UID différents
J'ai l'utilisateur "Apache" configuré localement avec UID = 123 et dans le répertoire NIS avec le même nom ("Apache") mais un UID différent = 456. En fonction de l'ordre de démarrage et de la dépendance du service, l'utilisateur local peut être utilisé avant que l'utilisateur NIS ne soit disponible. Cela signifie également que lorsque vous affichez les noms d'utilisateur, cela sera source de confusion, les deux apparaîtront sous le nom "Apache". Uniquement lorsque vous regardez les UID numériques (par exemple en faisant ls -ln, vous verrez la différence. Exemple: [root@mymachine]# ls -l drwxr-x--- 4 Apache ggg1 88 May 31 17:12 file1 drwxr-x--- 4 Apache ppp2 88 May 31 17:12 file2 voyez que l'UID est différent pour file2 (456 au lieu de 123): [root@mymachine]# ls -ln drwxr-x--- 4 123 48 88 May 31 17:12 file1 drwxr-x--- 4 456 48 88 May 31 17:12 file2
groupe différent défini dans Apache config
Un autre problème que j'avais avec l'incompatibilité des utilisateurs et l'erreur d'autorisation résultante était lorsque je limitais l'accès aux fichiers à l'aide du groupe "httpd". Il s’agissait du groupe principal d’utilisateurs "Apache" (affiché à l’aide de id ou getent). Apache démarre en tant que root, puis bascule vers un utilisateur configuré et supprime l’autorisation. L'utilisateur sur lequel il bascule est défini dans le paramètre /etc/httpd/conf/httpd.conf par User. Voici le problème cependant - le groupe (GID) dans lequel le processus sera exécuté est PAS le groupe principal de cet utilisateur. Le groupe est défini dans le même fichier de configuration par le paramètre Group.
Donc dans mon cas c'était (/ etc/httpd/conf/httpd.conf): User Apache Group Apache
Et l'accès au répertoire a été accordé comme suit: drwxr-x--- 4 someuser httpd 88 May 31 17:12 mydir
Parce que httpd (GID = 444) était le groupe principal de cet utilisateur: [root@somemachine]# id Apache uid=48(Apache) gid=444(httpd) groups=444(httpd)
Il en résulta un certain temps de débogage jusqu'à ce que je réalise que Group dans le fichier de configuration était "Apache" et non "httpd".
Erreur de / var/log/httpd/error_log: [Fri May 31 17:13:40.070343 2019] [authz_core:debug] [pid 2527] mod_authz_core.c(809): [client 11.22.32.21:53824] AH01626: authorization result of Require all granted: granted [Fri May 31 17:13:40.070367 2019] [authz_core:debug] [pid 2527] mod_authz_core.c(809): [client 11.22.32.21:53824] AH01626: authorization result of <RequireAny>: granted [Fri May 31 17:13:40.070396 2019] [core:error] [pid 2527] (13)Permission denied: [client 11.22.32.21:53824] AH00132: file permissions deny server access: /var/www/html/somedir/otherdir/css/file1.txt
J'espère que ça aide.