Probleme mit nginx (403 Forbidden) und PHPMyAdmin

[f1n3]

System:
Debian 8 Jessie x64
Easy-WI 6.0 (installscript)
nginx 1.12.1
PHP5 + fpm (5.6.x.x)

Ich habe einen Subordner namens "downloads". Wenn ich auf diesen zugreifen will kommt 403. Soweit alles in Ordnung. Stelle ich nun "autoindex" auf "on" und restarte nginx, bleibt die Meldung trotzdem bestehen. Auf meiner Webseite habe ich auch eine "downloads.html" welche mir in einer Tabelle ein paar Texte anzeigt und einen "a href" Wert hat welcher auf "/downloads/bla.png" linkt. Wenn ich auf meiner Webseite aber nun die "downloads.html" Seite aufrufen möchte, kommt auch ein 403.

Struktur ist wie folgt: /home/web-2/htdocs/
Darin dann:

index.html
downloads.html
Ordner: downloads
-> bla.png
Ordner: style
-> style.css
-> background.jpg

Die "style.css" und den Hintergrund lädt er ohne Probleme. Auf den Ordner komme ich aber auch nicht drauf, selbst wenn "autoindex" auf an ist. Rufe ich die "style.css" aber direkt über "web-2.domain.de/style/style.css" auf, lässt er mich die Datei ansehen.
(Kurze Frage nebenbei: Wie stelle ich ein, dass die Seite alle benötigten Dateien aufrufen und ausführen kann, ich aber ein 403 bekomme wenn ich sie direkt aufrufen will?)

Versuche ich jedoch das selbe mit "web-2.domain.de/downloads/bla.png" kommt direkt ein 403.
Das komische ist ja auch, dass es meine "downloads.html" blockiert, da anscheinend der "a href" auf den "downloads" Ordner schon reicht. :/

Alle Ordner rechte angefangen von "root" bis tief ins /home/user/htdocs/downloads" haben "755" und "www-data" als "Group". Alle Dateien (.html / .png usw.) haben "644". Der Owner dieser Dateien ist "web-2". Also derjenige dem ich den Vhost angelegt habe.
nginx und php-fpm usw. laufen auch alle über "www-data" wie bei der Installation von EWI automatisch geschehen.
Doch egal was ich versuche, ich bekomme weder Zugriff auf diese eine Webpage noch auf den Ordner an sich.
Im log steht "*2 access forbidden by rule".

.conf

server {
   listen 80;
   server_name www.web-2.domain.de;
   return 301 $scheme://web-2.domain.de$request_uri;
}
server {
   listen 80;
   server_name web-2.domain.de;
   autoindex off;
   access_log /home//web-2/logs/access_web-2.domain.de.log;
   error_log /home//web-2/logs/error_web-2.domain.de.log;
   root /home//web-2/htdocs//;
   index index.php index.html index.htm;
   location / {
      try_files $uri $uri/ =404;
   }

location /downloads {
	autoindex on;
}

   location ~ .php$ {
      fastcgi_pass unix:/var/run/php-fpm-web-2.sock;
      include fastcgi.conf;
      fastcgi_index index.php;
      include fastcgi_params;
   }
}

Falls sich noch jemand mit Easy-WI auskennt. Ich habe auch versucht unter Anleitung (PHPMyAdmin) zu installieren. Wenn ich jedoch domain.de/phpmyadmin aufrufe kommt nur ein: 502 Bad Gateway.

Wie verknüpfe ich das nun richtig?

 

[RalphS]

Nimm mal die doppelten Slashes in den Pfaden weg. Die fliegen einem öfter mal um die Ohren.

Also statt
/home//web-2/htdocs//
lieber
/home/web-2/htdocs/.

 

[f1n3]

Wow.. ich hatte mich schon gewundert wieso mir EWI die automatisch da reingemacht hat, hab mir aber nichts dabei gedacht da bisher alles funktioniert hat. Nachdem ich nun alle doppelten Slashes entfernt habe, funktioniert endlich alles wie gewollt. (Y)

Noch ein Tipp wegen PHPMyAdmin?

Und wegen "(Kurze Frage nebenbei: Wie stelle ich ein, dass die Seite alle benötigten Dateien aufrufen und ausführen kann, ich aber ein 403 bekomme wenn ich sie direkt aufrufen will?)"

Sprich, die Seite lädt die "style.css" und wird beim Enduser dann auch angezeigt/übernommen. Wenn dieser aber nun auf "web-2.domain.de/style/style.css" geht, soll er eine 403 bekommen.

 

[RalphS]

linuxbabe.com mag mich grad nicht.

Steht nix in den nginx-Logs? "Normal" sollte phpMyAdmin auch ohne jede Konfiguration erstmal funktionieren, wenn auch noch nicht zu 100%.

Evtl fehlt Dir die eine oder andere essentielle PHP-Erweiterung für phpMyAdmin. Dann gibt es 5xx-Fehler (IIRC).

Re: Direktaufruf... nicht nach bestem Wissen und Gewissen. Immerhin muß "jeder" die Ressourcen lesen können, damit er sie anzeigen kann.

Eingebundene Scripts kannst Du absichern, indem Du einfach außerhalb des Webroots speicherst. Aber das, was die Benutzer kriegen sollen, das müssen sie auch irgendwie kriegen können.

Ggf wäre ein indirekter Zugriff eine Option: es gibt eine PHP-Datei, welche die Ressource lesen soll. Also sagen wir /style.php, ggf mit irgendeinem Parameter, falls ein Stylesheet ausgewählt werden muß.

Wenn Du jetzt in irgendeiner Form einen Schlüssel festlegst - entweder statisch oder dynamisch -- dann könntest Du diesem Script den Schlüssel mitgeben und dieses könnte dann nach Prüfung entweder "was" oder "nichts" anzeigen (oder 403 als Status: zurückgeben).

Nur muß der Schlüssel irgendwie generiert werden, irgendwo hingetan werden, und -idealerweise- irgendwie aufgefrischt werden. Denn der Schlüssel würde ja spätestens im Quellcode der generierten HTML-Datei zu finden sein.

"Perfekt" wäre sozusagen die Generierung eines Schlüssels, sobald index.php aufgerufen wird, welche diesen dann irgendwo ablegt (zB in einer Datenbank) und mit Terminierung diesen wieder löscht. Kostet natürlich Ressourcen.

Dann kann der gemeine Anwender nicht auf style.css zugreifen -- die gibt es im Webroot erst gar nicht -- und er kann auf style.php nur zugreifen, wenn er den richtigen Schlüssel kennt (und, ggf, den richtigen Selektor fürs richtige Stylesheet). Weiter einschränken geht mit Beschränkung der Gültigkeitsdauer des Schlüssels (siehe eins weiter oben).

Beides kann er sich aus dem Quellcode holen. Aber es wäre erstmal ein Schutz gegen 'pauschale' Zugriffe.

 

[Marek72]

/style.css gehört doch bestimmt zu einem Layout.. wenn es Bestandteil der Seite ist die der Webserver ausliefern soll, wäre doch die Frage warum ein User darauf nicht zugreifen sollen darf?

 

[f1n3]

Mhh, klingt schon einmal interessant. Ist jedoch für meine kleine, private Homepage dann doch ein zu großer Aufwand für mich als laien.

Die Daten, die nicht angezeigt/aufgerufen werden sollen, kann ich dann immer noch mit einem PW versehen samt .rar PW. Das reicht mir dann erst mal.

Zu PHPMyAdmin: War die Vorgehensweise wie im Tutorial oben denn überhaupt korrekt?
Vielleicht gab es ja auch nur Probleme wegen den doppelten Slashes. Hab es bisher nicht mehr probiert.

[EDIT]
PMA so wie beim Tutorial installiert = 502
In den logs sehe ich nichts.

Bei den anderen Tutorials hab ich es über nen symlink versucht. Dieser sagte mir dann:

[23-Aug-2017 05:11:03 Europe/Berlin] PHP Warning:  Unknown: open_basedir restriction in effect. File(/usr/share/phpmyadmin/index.php) is not within the allowed path(s): (/home/easywi_web/htdocs/:/home/easywi_web/tmp/) in Unknown on line 0
[23-Aug-2017 05:11:03 Europe/Berlin] PHP Warning:  Unknown: failed to open stream: Operation not permitted in Unknown on line 0

Anscheinend macht mir da EWI ein Strich durch die Rechnung. Hab aber auf deren Seite/Forum keine Anleitung gefunden wie man das nun einbindet. Die Möglichkeit im Webpanel besteht aber. Sofern ich einen funktionierenden Link habe. :/

 

[RalphS]

Das ist schon richtig so. Symlinks in virtuellen Pfaden sind ein Sicherheitsrisiko und werden deshalb standardmäßig nicht verarbeitet.

Führ zuerstmal php-cgi auf der Kommandozeile aus mit dem Pfad der index.php (aufpassen: den Pfad wirklich angeben).

Also zB so: php-cgi ./index.php
php-cgi index.php (ohne Pfad) durchsucht den in PHP konfigurierten Suchpfad, kein bestimmtes Verzeichnis.

Du solltest eine Ausgabe bekommen - "theoretisch" mit Hinweis auf einen Fehler.

ZB könnte das so aussehen (aufs Wesentliche eingekürzt):

Status: 500 Internal Server Error
X-Powered-By: PHP/7.1.8
Set-Cookie: pmaCookieVer=5; expires=Fri, 22-Sep-2017 10:30:16 GMT; Max-Age=2592000; path=/; HttpOnly
Content-Type: text/html; charset=utf-8

...
<body>
<h1>phpMyAdmin - Error</h1>
<p>The <a href="./url.php?url=https%3A%2F%2Fsecure.php.net%2Fmanual%2Fen%2Fbook.session.php" target="Documentation"><em>session</em></a> extension is missing. Please check your PHP configuration.</p>
</body>

In diesem Fall also die session-Erweiterung aktivieren (ggf erstmal installieren) und dann neu schauen.

Als nächtes nachprüfen, ob die konfigurierte DB-Verbindung funktioniert. Jedenfalls dann, wenn die PHP-Konfiguration okay ist und es trotzdem nicht geht. Dazu:

- config.inc.php anschauen (im Stamm von phpMyAdmin)
- Dort gibt's einen Bereich mit

$cfg['Servers'][$i]['pmadb'] = 'PMADB';
<andere Zeilen>
$cfg['Servers'][$i]['controlhost'] = '';
$cfg['Servers'][$i]['controlport'] = '';
$cfg['Servers'][$i]['controluser'] = 'DBUSER';
$cfg['Servers'][$i]['controlpass'] = 'DBPASS';

Evtl sind Host und Port ebenfalls gesetzt.

- Dann verbindest Du Dich mit ganz genau diesen Parametern mit der Datenbank:

mysql -uDBUSER -p -DPMADB -hDBHOST -PDBPORT

wobei Du jeweils die Werte eingibst, so wie sie in der config-Datei festgelegt waren. Werte, die dort nicht gesetzt sind, läßt Du komplett weg aus der Befehlszeile. Paßwort sollte immer gesetzt sein (-p); ist es das nicht, solltest Du das schnellstmöglich ändern.

Das sollte dann in etwa so aussehen:

$ mysql -upmauser -p -Dphpmyadmin
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is -1
Server version: 10.1.21-MariaDB FreeBSD Ports

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [phpmyadmin]>

Bekommst Du den MariaDB-Prompt, ist alles gut. Gibt es Fehlermeldungen, haben wir das Problem gefunden (poste diese ggf, falls Du damit nichts anfangen kannst).

Hast Du den Prompt:

MariaDB [phpmyadmin]>show tables;
+------------------------+
| Tables_in_phpmyadmin   |
+------------------------+
| pma__bookmark          |
| pma__central_columns   |
| pma__column_info       |
| pma__designer_settings |
| pma__export_templates  |
| pma__favorite          |
| pma__history           |
| pma__navigationhiding  |
| pma__pdf_pages         |
| pma__recent            |
| pma__relation          |
| pma__savedsearches     |
| pma__table_coords      |
| pma__table_info        |
| pma__table_uiprefs     |
| pma__tracking          |
| pma__userconfig        |
| pma__usergroups        |
| pma__users             |
+------------------------+
19 rows in set (0.14 sec)

MariaDB [phpmyadmin]>

Wird das so oder ähnlich angezeigt, ist alles gut.
Wird etwas gänzlich anderes angezeigt, dann hast Du die falsche Datenbank erwischt. Leg eine neue an mit

 create database phpmyadmin;

. In jedem Fall kommst Du mit

\q

wieder raus.

Dann den Namen der eben erstellten Datenbank in der config.inc.php unter $cfg... 'pmadb' (siehe oben) eintragen.

 

[f1n3]

Die symlinks wurden entfernt und habe es wieder über die Vhosts geregelt.

  location ~ /phpmyadmin/(.+\.php)$ {
    fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
    include snippets/fastcgi-php.conf;

habe ich zu:

  location ~ \.php$ {
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    try_files $fastcgi_script_name =404;
    set $path_info $fastcgi_path_info;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_param PATH_INFO $path_info;
    include /etc/nginx/fastcgi.conf;
    fastcgi_index index.php;

geändert, da EWI php5-fpm benutzt statt php5-cgi. Oder brauche ich beides? Dann würde es mich wundern wieso er dies nicht gleich mitinstalliert. Oder ich habe den Ordner noch nicht gefunden.

Ich habe mal test-weise eine "info.php" hochgeladen mit:

<?php
phpinfo();
?>

Wenn ich diese aufrufe kommt nur: "No input file specified."
Das selbe mittlerweile auch wenn ich PMA aufrufen möchte, nachdem ich die fastcgi Parameter geändert habe.


Wenn ich "php-cgi ./index.php" in die Kommandzeile eingebe, kommt ein "command not found".
Sorry, wenn das falsch ist. Ich fuchse mich da gerade so rein. Und ja, mir ist das Thema Sicherheit bewusst.

Die Configs der PMA stimmen alle und ist alles eingetragen. Über die Kommandozeile kann ich mich auch als PMA einloggen und sehe auch die Tabellen. Daran liegt es schon mal nicht.

 

[RalphS]

Mit fpm hab ich mich nur kurz rumgeärgert und das dann zu den Akten getan.

Ich "denke" zumindest, daß es was mit der fpm-Konfiguration zu tun haben könnte. Denn das ist ja nochmal ein dazwischengeschobener Proxy.

Vorschlag: probier's erstmal über php-cgi. Oder (leider keine Ahnung) vielleicht gibt es auch ein in-process Modul für den nginx, so wie mod_php für apache.
php-cgi ist zwar weniger performant als fpm, aber dafür ist es (imo) einfacher zu konfigurieren. Für phpMyAdmin sollte es jedenfalls keinen Unterschied machen.

 

[f1n3]

Ich möchte eigentlich schon bei FPM bleiben, da das komplette System (EWI) so ausgeliefert wurde.
Wieso es jedoch nicht funktioniert, ist mir ein Rätsel. Die FAQ/Manual auf deren Seite ist leider auch sehr bescheiden und in ihrem Gitchannel bekomme ich keine Antwort dazu. (Ist denen wohl zu blöd bei dem "kleinen Fehler", nehme ich mal an.)

Hatte die Tage jetzt auch keine Zeit noch einmal selbst zu schauen. Mache ich dann Anfang kommender Woche.
Problem ist jedoch immer noch das selbe.

 

[RalphS]

Funktioniert denn ein eigenes kleines PHP-Script (als phpinfo()) mit fpm? Falls ja, wäre schon mal was gewonnen. Falls nicht, wäre zumindest klar, daß da der Wauwau in den Brennesseln schläft.

 

[f1n3]

Mit der Konfiguration die gerade läuft, anscheinend ja nicht.

Habe jetzt test weise mal versucht einen neuen Vhost anzulegen um zu sehen ob es mit der Standard Konfiguration vom Panel klappt. Dieser wird erstellt, die ".conf" auch. Jedoch, auch nach neustart von "nginx" komme ich nicht auf die Seite.

Meine Hauptdomain wird bei jedem Vhost angezeigt. Auch eine Datei direkt aufrufen über die URL funktioniert nicht -> 404

.conf der Vhosts die erstellt werden sehen immer so aus wie im 1. Post. (Ohne die doppelten "/")

.conf der Hauptdomain:

server {
    listen 80;
    server_name domain.de;
    return 301 https://domain.de$request_uri;
}
server {
    listen 443 ssl;
    ssl_certificate /etc/nginx/ssl/domain_de.crt;
    ssl_certificate_key /etc/nginx/ssl/domain_de.key;
    root /home/web-2/htdocs/;
    index index.html index.htm index.php;
    server_name domain.de;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        try_files $fastcgi_script_name =404;
        set $path_info $fastcgi_path_info;
        fastcgi_param PATH_INFO $path_info;
        fastcgi_index index.php;
        include /etc/nginx/fastcgi.conf;
        fastcgi_pass unix:/var/run/php5-fpm-domain_de.sock;
    }
location /phpmyadmin {
  root /usr/share/;
  index index.php;
  try_files $uri $uri/ =404;

  location ~ ^/phpmyadmin/(doc|sql|setup)/ {
    deny all;
  }

  location ~ \.php$ {
    try_files $fastcgi_script_name =404;
    set $path_info $fastcgi_path_info;
    fastcgi_pass unix:/var/run/php5-fpm-domain_de.sock;
    fastcgi_param PATH_INFO $path_info;
    include /etc/nginx/fastcgi.conf;
    fastcgi_index index.php;
  }
 }
}

Das Webpanel läuft ja auch mit .php und funktioniert.

Ich werde langsam Wahnsinnig mit EWI.
An sich super Panel mit allem was ich benötige. Funktioniert auch alles wie gewollt. Nur der Webspace macht Probleme. :/

 

[RalphS]

Wait, also funktionieren die VHosts schon nicht? Die sollen ja eigentlich ihre eigene Konfiguration verwenden

Spontan fällt mir das "root /usr/share" für phpmyadmin auf. Das wird wohl so vermutlich nicht gehen.

ROOT definiert den Stamm des Webservers (des VHosts) im Dateisystem. Nach dem was Du geschrieben hast, findet sich das in /home/web-2/htdocs .

LOCATION definiert den Stamm auf dem Webserver, als virtuelles Dateisystem. Du könntest hier /PMP hintun und dann findet sich die Websit eeben unter domain.de/PMP. Stamm für den Webserver(den VHost) ist immer / .

Für die restlichen Zuordnungen gibt es den Alias. Der verweist physisch (dateisystem) auf virtuell (das stellt der Webserver bereit).
Also sinngemäß so:

location /PMP {
alias /usr/share/phpmyadmin
}

sodaß Zugriffe auf domain.de/PMP/$uri und darunter auf /usr/share/phpmyadmin/$uri umgebogen werden.

 

[f1n3]

Ich glaube, wir kommen der Sache langsam näher.

Nachdem ich jetzt einen "alias" statt einem "root" definiert habe, funktionieren auch die Vhost-Configs wieder. Sprich jede Seite/Domain ist erreichbar.

Problem ist jetzt nur das er mir ein "502 Bad Gateway" anzeigt. Also mal in die logs geschaut und siehe da:

2017/08/28 20:57:01 [crit] 3766#3766: *1901 connect() to unix:/var/run/php-fpm-web-3.sock failed (2: No such file or directory)

Beim erstellen der Vhosts über das Webpanel wird anscheinend kein .sock erstellt, weshalb auch kein FPM läuft und dadurch PHP auch nicht funktioniert. HTML Seiten laufen nämlich wunderbar.

 

[RalphS]

Andersrum, der laufende FPM erstellt das Socket.

Schau mal nach, ob FPM läuft und das Socket einfach woanders rumliegt oder ob mit FPM was nicht paßt.

 

[f1n3]

FPM läuft, Socket kann ich nirgends finden. FPM-Configs sehen soweit ICH das beurteilen kann, gut aus. :/

Einer aus dem Gitter-Channel meinte: "leg den Socket in das home Verzeichnis des Users und stell die rechte ein... sollte dann funktionieren."

Aber eigentlich sollte er die Sockets ja selbst erstellen und im "/run" Ordner ablegen, tut er aber nicht.

 

[RalphS]

Spontan: FPM bindet an ein TCP-Socket und nicht an ein UNIX-Socket.

Prüf das mal. Müßte -iirc- mit netstat -b oder netstat --program gehen, aber ich hab hier grad kein Linux zum gucken. (BSD verwendet sockstat.)

Wenn das ein TCP-Socket sein sollte, unter fastcgi_pass als Nameort eintragen, also zB localhost:12345.

Was mir auch grad auffällt, ist, daß in Deiner geposteten Konfiguration immer was anderes für den FPM Socket eingetragen ist. Aber keine Ahnung, ob FPM für jede Website einen eigenen Socket belegen muß oder nicht (intuitiv würd ich davon ausgehen, daß ein Socket für alles genügt).

 

[f1n3]

"netstat -b" zeigt mir nichts brauchbares an.

Unter "netstat --program" folgendes:

/run/systemd/journal/socket
unix  3      [ ]         STREAM     CONNECTED     249720564 4390/php-fpm.conf)

/run/systemd/journal/stdout
unix  3      [ ]         STREAM     CONNECTED     249720565 4390/php-fpm.conf)

 

[RalphS]

Guter Gott, systemd.

Schuß ins Blaue: Setz mal localhost:9000 als fastcgi_pass. Das ist das Standard-Socket für fpm (via tcp/ip). Vielleicht tut das ja schon.

Ansonsten... gibt's nirgends einen php-fpm Prozeß, der irgendein Socket geöffnet hat? Vielleicht gibt

lsof | grep -E '(fpm|sock)'

näheren Aufschluß. Unix-Sockets sollten als Dateisystemobjekte mit lsof erfaßt werden.