Ich kann nicht auf das Verzeichnis zugreifen, in dem ich Gruppenmitglied bin

Auf meinem Webserver habe ich ein Verzeichnis 'www', das über die Berechtigung drwxrwxr--und die Benutzergruppe verfügt, root:www-datadamit Apache darauf zugreifen kann.

Jetzt habe ich mein Konto zur Gruppe www-data with hinzugefügt

sudo usermod -g www-data myuser

und wenn ich das tue, groupsdann www-dataist es unter ihnen, aber wenn ich versuche, einfach hineinzudatieren, bekomme ich 'Erlaubnis verweigert'.

Wenn ich den Benutzer in "myuser" ändere oder die Gruppe auf eine andere Gruppe setze, der ich angehöre, kann ich einsteigen.

Vermisse ich etwas

Die Gruppenliste Ihres Prozesses ist zum Zeitpunkt der Anmeldung festgelegt, sodass Sie sich erneut anmelden müssen, damit die Änderung wirksam wird.

Ich würde auch vorschlagen, dass Sie www-dataals zusätzliche Gruppe und nicht als primäre Gruppe hinzufügen (die auf eine Gruppe festgelegt ist, zu der nur Sie gehören. Sie sollten dies mit den folgenden Befehlen tun können:

# Reset to your original primary group
sudo usermod -g myuser myuser
# Add an extra supplementary group
sudo usermod --append -G www-data group

Wenn Sie möchten, dass von Ihnen erstellte Dateien von anderen Mitgliedern der www-dataGruppe gelesen werden können, passen Sie Ihre Umask entsprechend an:

umask 002

Da Ihre primäre Gruppenmitgliedschaft eine persönliche Gruppe ist, sollte dies die Sicherheit der von Ihnen erstellten Dateien nicht beeinträchtigen.

Es lohnt sich auch, das setgidBit für Verzeichnisse zu setzen, in denen Sie Dateien erstellen: Dies führt dazu, dass Dateien den Gruppenbesitz des übergeordneten Verzeichnisses erben:

chmod g+s www/

Für mich war es etwas anderes, was zu diesem Fehler führte

gleicher Benutzername mit zwei verschiedenen UIDs

Ich habe den Benutzer "Apache" lokal mit UID = 123 und im NIS-Verzeichnis mit demselben Namen ("Apache"), aber unterschiedlicher UID = 456 konfiguriert. Abhängig von der Startreihenfolge und der Serviceabhängigkeit kann ein lokaler Benutzer verwendet werden, bevor ein NIS-Benutzer verfügbar ist. Das bedeutet auch, wenn Sie Benutzernamen anzeigen, ist dies verwirrend, beide werden als "Apache" angezeigt. Nur wenn Sie sich numerische UIDs ansehen (zum Beispiel, wenn Sie dies tun ls -ln, werden Sie den Unterschied sehen. Beispiel: [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 Sehen Sie, dass die UID für Datei2 unterschiedlich ist (456 statt 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

andere Gruppe in der Apache-Konfiguration definiert

Ein weiteres Problem, das ich mit der Nichtübereinstimmung der Benutzer und dem daraus resultierenden Berechtigungsfehler hatte, war, als ich den Zugriff auf Dateien mithilfe der Gruppe "httpd" einschränkte. Dies war die primäre Gruppe von Benutzern "Apache" (die mit idoder angezeigt wurde getent). Apache wird als Root gestartet, wechselt dann zum konfigurierten Benutzer und löscht die Berechtigung. Der Benutzer, zu dem es wechselt, wird /etc/httpd/conf/httpd.confdurch UserParameter definiert . Hier ist jedoch das Problem - die Gruppe (GID), die der Prozess ausführen wird, ist NICHT die primäre Gruppe dieses Benutzers. Die Gruppe wird in derselben Konfigurationsdatei nach GroupParametern definiert.

In meinem Fall war es also ( /etc/httpd/conf/httpd.conf ): User apache Group apache

Und dem Verzeichnis wurde folgender Zugriff gewährt: drwxr-x--- 4 someuser httpd 88 May 31 17:12 mydir

Weil httpd (GID = 444) die primäre Gruppe dieses Benutzers war: [root@somemachine]# id apache uid=48(apache) gid=444(httpd) groups=444(httpd)

Es führte einige Zeit zum Debuggen, bis mir klar wurde, dass Groupin der Konfigurationsdatei "Apache" und nicht "httpd" war.

Fehler aus / 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

Ich hoffe das hilft.