Nach Upload über PHP - Dateien gehören www-data (nginx, php-fpm, ISPConfig)

Knobibrot · 22. Nov. 2019

Hallo zusammen,

auf dem Server läuft Ubuntu 18.04, eingerichtet mit dem Perfect Server Tutorial.
Webserver ist ein nginx mit PHP-FPM 7.2

Ich habe nun folgendes Problem: Der PHP-FPM läuft im mit User: www-data
Wenn ich also jetzt etwas über PHP hochlade, dann landet es zwar im richtigen Ornder, aber mein Webnutzer kann nicht richtig drauf zugreifen, weil die Datei www-data gehört und nicht clientXY. Was kann ich tun um dieses Problem zu lösen?

Danke und Grüße,
Knobibrot

Till · 22. Nov. 2019

Der php-fpm der website läuft bei ispconfig nginx nie als www-data, es gibt einen der als www-data läuft, der wird aber nicht von ispconfig verwendet es ist der default pool. Ich vermute mal Du hast etwas in das nginx direktiven Feld eingetragen, poste das bitte mal. Meine Vermutung ist dass Du da aus Versehen den PHP handler überschrieben hast.

Knobibrot · 22. Nov. 2019

Hey Till,

danke für die schnelle Antwort.
im nginx direktiven Feld steht eigentlich nix davon drin:

Code:

location / {
                index index.php;    
                try_files $uri $uri/ /index.php/$uri?$args;
    }

location /roundcube {
               root /usr/share/;
               index index.php index.html index.htm;
               location ~ ^/roundcube/(.+\.php)$ {
                       try_files $uri =404;
                       root /usr/share/;
                       fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
                       fastcgi_param HTTPS on; # <-- add this line
                       fastcgi_index index.php;
                       fastcgi_param SCRIPT_FILENAME $request_filename;
                       include /etc/nginx/fastcgi_params;
                       fastcgi_param PATH_INFO $fastcgi_script_name;
                       fastcgi_buffer_size 128k;
                       fastcgi_buffers 256 4k;
                       fastcgi_busy_buffers_size 256k;
                       fastcgi_temp_file_write_size 256k;
                       fastcgi_intercept_errors on;
               }
               location ~* ^/roundcube/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ {
                       root /usr/share/;
               }
        }
        location /webmail {
               rewrite ^/* /roundcube last;
        }

Allerdings hab ich dann mal direkt in der kompletten config nachgesehen und dort seltsamerweise 2 PHP Blöcke gefunden:

Code:

      location ~ \.php(/|$) {
            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
            fastcgi_param HTTPS $fastcgi_https;
            fastcgi_index index.php;
            include /etc/nginx/fastcgi_params;
        }

        location @php {
            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            fastcgi_param HTTPS $fastcgi_https;
            include /etc/nginx/fastcgi_params;
            fastcgi_pass unix:/var/lib/php7.2-fpm/web1.sock;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_intercept_errors on;
         }

und klar, dass der erste Block ausgeführt wird, mit generischem FPM... ich muss der Sache mal auf den Grund gehen um rauszufinden wo dieser überflüssige Block herkommt.

Knobibrot · 23. Nov. 2019

Ok jetzt wirds seltsam.

Wenn ich den ersten Block raus schmeiße und den 2. mit fastcgi_pass unix:/var/lib/php7.2-fpm/web1.sock; drin lasse, bekomme ich beim Aufruf der index.php ein "403" Error.

gibt's irgendwelche logs oder configs die ich dir zeigen kann?

Till · 23. Nov. 2019

Zitat von Knobibrot:
Wenn ich den ersten Block raus schmeiße und den 2. mit fastcgi_pass unix:/var/lib/php7.2-fpm/web1.sock; drin lasse,

genau, das ist der richtige Ansatz, der erste Block ist falsch, also nutzt einen falschen fpm daemon.

Die PHP location die ein aktuelles ispconfig generiert sieht in etwa so aus (andere PHP version bei mir):

Code:

 location ~ \.php$ {
            try_files /71629c528c1aabeb56f92718c0bc54df.htm @php;
        }

        location @php {
            try_files $uri =404;
            include /etc/nginx/fastcgi_params;
            fastcgi_pass unix:/var/lib/php7.3-fpm/web2.sock;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_intercept_errors on;
        }

Ich würde an Deiner Stelle mal alles aus den nginx Direktiven der website raus nehmen und dann mal schauen wie die generierte datei aussieht. Du solltest in den nginx direktiben den PHP handler nicht überschreiben und falls Du es doch machen musst, dann verwende die variable {FASTCGIPASS} welche den pfad zum korrekten fpm socket enthält.

Zitat von Knobibrot:
gibt's irgendwelche logs oder configs die ich dir zeigen kann?

Ja, das error.log im Log Verzeichnis der website.

Knobibrot · 23. Nov. 2019

Hier kommt jetzt die von ISPConfig erzeugte vhost-Config.
Da wurde jetzt wirklich gar nichts dran geändert. Keine eigenen Direktiven und sie kommt so 1:1 aus ISPConfig. Ich hab lediglich die IP und die Domain anonymisiert.

Code:

server {
        listen xx.xxx.xxx.xxx:80;
        listen xx.xxx.xxx.xxx:443 ssl;
                ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_certificate /var/www/clients/client0/web1/ssl/domain.de-le.crt;
        ssl_certificate_key /var/www/clients/client0/web1/ssl/domain.de-le.key;

        server_name domain.de www.domain.de;

        root   /var/www/domain.de/web/;

        if ($scheme != "https") {
            rewrite ^ https://$http_host$request_uri? permanent;
        }


        index index.html index.htm index.php index.cgi index.pl index.xhtml;



        error_page 400 /error/400.html;
        error_page 401 /error/401.html;
        error_page 403 /error/403.html;
        error_page 404 /error/404.html;
        error_page 405 /error/405.html;
        error_page 500 /error/500.html;
        error_page 502 /error/502.html;
        error_page 503 /error/503.html;
        recursive_error_pages on;
        location = /error/400.html {

            internal;
        }
        location = /error/401.html {

            internal;
        }
        location = /error/403.html {

            internal;
        }
        location = /error/404.html {

            internal;
        }
        location = /error/405.html {   
        
            internal;
        }
        location = /error/500.html {

            internal;
        }
        location = /error/502.html {

            internal;
        }
        location = /error/503.html {

            internal;
        }

        error_log /var/log/ispconfig/httpd/domain.de/error.log;
        access_log /var/log/ispconfig/httpd/domain.de/access.log combined;

        location ~ /\. {
                        deny all;
        }
        location ~ /\. {
                        deny all;
        }

        location ^~ /.well-known/acme-challenge/ {
                        access_log off;
                        log_not_found off;
                        auth_basic off;
                        root /usr/local/ispconfig/interface/acme/;
                        autoindex off;
                        index index.html;
                        try_files $uri $uri/ =404;
        }

        location = /favicon.ico {
            log_not_found off;
            access_log off;
            expires max;
            add_header Cache-Control "public, must-revalidate, proxy-revalidate";
        }

        location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;
        }
       location /stats/ {                                                                                                                                                                   
            index index.html index.php;
            auth_basic "Members Only";
            auth_basic_user_file /var/www/clients/client0/web1/web//stats/.htpasswd_stats;
        }

        location ^~ /awstats-icon {
            alias /usr/share/awstats/icon;
        }

        location ~ \.php$ {
            try_files /eef9c493f0dc1209dc82c97f47e161c7.htm @php;
        }

        location @php {
            try_files $uri =404;
            include /etc/nginx/fastcgi_params;
            fastcgi_pass unix:/var/lib/php7.2-fpm/web1.sock;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_intercept_errors on;
        }


}

Mit dieser Config kriege ich einen 403 Error.

Hier das error.log der entsprechenden Website.

Code:

2019/11/23 13:27:54 [error] 4612#4612: *83 open() "/var/www/domain.de/web/index.php/Notifications.html" failed (20: Not a directory), client: 109.91.33.153, server: domain.de, request: "GET /index.php/Notifications.html?s=&load HTTP/1.1", host: "domain.de", referrer: "https://domain.de/index.php/?s="
2019/11/23 13:28:11 [error] 4612#4612: *87 open() "/var/www/domain.de/web/index.php/Notifications.html" failed (20: Not a directory), client: 91.97.242.110, server: domain.de, request: "GET /index.php/Notifications.html?s=&load HTTP/1.1", host: "domain.de", referrer: "https://domain.de/index.php/?s="
2019/11/23 13:29:59 [error] 4612#4612: *109 open() "/var/www/domain.de/web/index.php/Notifications.html" failed (20: Not a directory), client: 95.223.106.69, server: domain.de, request: "GET /index.php/Notifications.html?s=&load HTTP/1.1", host: "domain.de", referrer: "https://domain.de/index.php/?s="
2019/11/23 13:30:17 [error] 4612#4612: *114 open() "/var/www/domain.de/web/index.php/Notifications.html" failed (20: Not a directory), client: 87.122.216.47, server: domain.de, request: "GET /index.php/Notifications.html?s=&load HTTP/1.1", host: "domain.de", referrer: "https://domain.de/index.php/Points/?"
2019/11/23 13:31:21 [error] 4612#4612: *155 FastCGI sent in stderr: "Access to the script '/var/www/domain.de/web' has been denied (see security.limit_extensions)" while reading response header from upstream, client: 188.210.48.21, server: domain.de, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/lib/php7.2-fpm/web1.sock:", host: "www.domain.de"

Till · 23. Nov. 2019

die nginx config ist jetzt ok, also das eigentliche Problem wurde vehoben. Ich vermute mal Du hast irgendwelche Rechte an wem web oder den scripts verändert um Deion ursprüngliches Problem zu beheben und sie auf www-data oder so geändert? Denn das führt dazu dass die Seite nicht mehr funktionieren kann.

außerdem kannst Du jetzt folgendes wieder ins nginx direktiven feld einfügen, vermute mal Du nutzt Wordpress?

Code:

location / {
                index index.php;   
                try_files $uri $uri/ /index.php/$uri?$args;
    }

Knobibrot · 23. Nov. 2019

nein, auf dem Server ist kein Wordpress drauf. Da läuft eqdkp - das ist so ein WOW Guilden CMS. Allerdings kommt das Problem kommt schon bei einer simplen info.php

Bezüglich Rechte: Ein paar Unterordner des /web Verzeichnisses haben chmod 777, aber an den Benutzern und Gruppen habe ich nichts geändert.

Ich bin ziemlich ratlos, da die logs ja auch nix richtiges hergeben. Klar, da steht 403, aber das sagt der Browser auch. Kann es sein, dass der PHP-FPM nicht mit dem richtigen User ausgeführt wird und er deswegen keinen Zugriff erhält? Kann ich das irgendwo nachschauen?

Also um ehrlich zu sein: ich hab schon sehr viele Server mit ISPConfig aufgesetzt, allerdings immer Apache. das ist jetzt der erste mit nginx.
Allerdings scheint auf dem Ding nichts richtig zu funktionieren:

Diese Problem hier mit PHP-FPM
Der Mail-Server nimmt keine Mails an (Der Absender erhält ein simples connect to domain.de[xx.xxx.xxx.xxx]:25: Connection refused
Roundcube lässt sich nicht installieren - Datenbank zugriff verweigert.

Und das sind alles Probleme die nach einer ganz frischen Installation auftreten. Am mail-system hab ich zb gar nichts verändert. nur die Config-Einträge wie sie im Tutorial stehen und die auch 3x überprüft.
Aber gut, das sind andere Themen für andere Threats.

Till · 23. Nov. 2019

Ich hab zig nginx server, alle nach perfect server tutorial installiert und alle laufen einwandfrei, daran liegt es also schonmal nicht. Nginx ist aber nicht so einfach wie apache da man je nach cms halt bestimmte zusatz Regeln braucht wenn die cms so etwas wie 'clean urö's' nutzen, also vitrtuelle url's die auf ein zentrales PHP script gemapped werden sollen.

Till · 23. Nov. 2019

Vielleicht ist es am einfachsten wenn Du die ganze website nochmal löschst in ispconfig, dann neu anlegst und dann erstmal nur eine info.php datei anlegst und die ausgabe davon prüfst. Dann weißt Du ob das web geht und kannst dann stück für Stück Änderungen vornehmen und nachvollziehen an welcher deeiner Änderungen es liegt wenn es dann nicht mehr funktioniert.

Den code für phpmyadmin brauchst Du übrigens nicht, der ist optional, denn Du erreichst phpmyadmin ja auf port 8081 /phpmyadmin, ich nutze den auch nirgends.

Knobibrot · 24. Nov. 2019

hi Till,

soweit komme ich gar nicht.
Hab nun folgendes gemacht:
Neue Website angelegt. --> HTML geht.
Dann info.php angelegt. Resultat: 403 Error.

In der error.log steht:

Code:

2019/11/24 01:45:21 [error] 17282#17282: *229 FastCGI sent in stderr: "Access to the script '/var/www/test.domain.de/web' has been denied (see security.limit_extensions)" while reading response header from upstream, client: 188.210.48.21, server: test.domain.de, request: "GET /info.php HTTP/1.1", upstream: "fastcgi://unix:/var/lib/php7.2-fpm/web2.sock:", host: "test.domain.de"
2019/11/24 01:45:32 [error] 17282#17282: *229 FastCGI sent in stderr: "Access to the script '/var/www/test.domain.de/web' has been denied (see security.limit_extensions)" while reading response header from upstream, client: 188.210.48.21, server: test.domain.de, request: "GET /info.php HTTP/1.1", upstream: "fastcgi://unix:/var/lib/php7.2-fpm/web2.sock:", host: "test.domain.de"

du siehst also: Es wird kein einziges PHP Script ausgeführt und das mit standard Einstellungen ohne irgendwelchen Direktiven.

Kann es noch an der fastcgi_params liegen?
Ich glaube an der hatte ich auch mal rumgespielt.
Da steht aktuell folgendes drin:

Code:

fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param  PATH_INFO          $fastcgi_path_info;
fastcgi_param  PATH_TRANSLATED    $document_root$fastcgi_path_info;

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  REQUEST_SCHEME     $scheme;
fastcgi_param  HTTPS              $https if_not_empty;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

#fastcgi_param  PATH_INFO          $fastcgi_path_info;
#fastcgi_param  PATH_TRANSLATED    $document_root$fastcgi_path_info;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

Till · 24. Nov. 2019

Poste bitte mal die Ausgabe von:

ls -la /var/www/test.domain.de/

und

ls -la /var/www/test.domain.de/web/

Knobibrot · 24. Nov. 2019

Gerne.

ls -la /var/www/test.domain.de/

Code:

drwxr-xr-x 9 root root    4096 Nov 24 01:32 .
drwxr-xr-x 5 web1 root    4096 Nov 24 01:32 ..
drwxr-xr-x 2 web2 client1 4096 Nov 24 01:32 cgi-bin
drwxr-xr-x 2 root root    4096 Nov 24 01:32 log
drwx--x--- 2 web2 client1 4096 Nov 24 01:32 private
drwx------ 2 web2 client1 4096 Nov 24 01:32 .ssh
drwxr-xr-x 2 root root    4096 Nov 24 01:32 ssl
drwxrwx--- 2 web2 client1 4096 Nov 24 01:32 tmp
drwxr-x--x 4 web2 client1 4096 Nov 24 01:40 web

ls -la /var/www/test.domain.de/web/

Code:

drwxr-x--x 4 web2 client1 4096 Nov 24 01:40 .
drwxr-xr-x 9 root root    4096 Nov 24 01:32 ..
drwxr-xr-x 2 web2 client1 4096 Nov 24 01:32 error
-rwxr-xr-- 1 web2 client1 7358 Nov 24 01:32 favicon.ico
-rwxr-xr-- 1 web2 client1 1915 Nov 24 01:32 index.html
-rwxr-xr-- 1 web2 client1   20 Nov 24 01:40 info.php
-rwxr-xr-- 1 web2 client1   14 Nov 24 01:32 robots.txt
drwxr-xr-x 2 web2 client1 4096 Nov 24 01:32 stats

ein chmod +x info.php bringt übrigens auch nix.

Knobibrot · 24. Nov. 2019

Till, es geht.

Ich hab bei mir lokal einen neuen Ubuntu 18.04 Server nach dem Perfect Server Tutorial aufgesetzt um an eine saubere "fastcgi_params" Datei zu kommen. Diese habe ich dann auf den Problem-Server kopiert und jetzt geht es.

Ich danke dir trotzdem für deine Hilfe.

Falls jemand das gleiche Problem hat: Hier die saubere fastcgi_params:

Code:

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  REQUEST_SCHEME     $scheme;
fastcgi_param  HTTPS              $https if_not_empty;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

Knobibrot · 24. Nov. 2019

@Till kleiner Nachtrag:

Ich musste die fastcgi_params entsprechend anpassen, weil das CMS es so haben will:

EQdkp Plus

The Gamer CMS & DKP System

wiki.eqdkp-plus.eu

Die verlangen, dass folgende FASTCGI Parameter gesetzt werden:

Code:

fastcgi_param   PATH_INFO               $fastcgi_path_info;
fastcgi_param   PATH_TRANSLATED         $document_root$fastcgi_path_info;

Und exakt das ist die Bruchstelle. Dadurch kommt der 403 zustande.
Einzige Möglichkeit es zu umgehen ist, fpm nicht mit dem Nutzer "web2" laufen zu lassen, sondern den standard php-fpm zu nutzen, der dann aber mit www-data läuft.

Mit Apache solls diese Probleme wohl nicht geben. Wenn dir jetzt nicht zufällig dazu eine Idee kommt, werde ich den Server wohl noch einmal neu aufsetzen, aber dann mit einem Apache.

Till · 25. Nov. 2019

Versuch mal folgendes in das nginx direktiven Feld einzufügen:

Code:

location @php {##merge##
fastcgi_param   PATH_INFO               $fastcgi_path_info;
fastcgi_param   PATH_TRANSLATED         $document_root$fastcgi_path_info;
}

Knobibrot · 27. Nov. 2019

Hat leider auch nicht funktioniert.
Daher bin ich jetzt auf Apache umgestiegen.
Hier funktioniert alles wie es soll. Trotzdem danke für die Hilfe.

Nach Upload über PHP - Dateien gehören www-data (nginx, php-fpm, ISPConfig)

Knobibrot

Member

Till

Administrator

Knobibrot

Member

Knobibrot

Member

Till

Administrator

Knobibrot

Member

Till

Administrator

Knobibrot

Member

Till

Administrator

Till

Administrator

Knobibrot

Member

Till

Administrator

Knobibrot

Member

Knobibrot

Member

Knobibrot

Member

EQdkp Plus

Till

Administrator

Knobibrot

Member

Werbung

Wir schützen deine Privatsphäre