Filezilla fehlende Zugriffsberechtigungen

Ein neuer Artikel wurde veröffentlicht
  • Hallo Community,


    ich habe ein Problem mit Filezilla. Ich kann im Ordner /var/www/html/ keine Daten bearbeiten.


    Ich habe dann die Befehle ausprobiert:


    Code
    1. sudo chown -R www-data:www-data /var/www
    2. sudo chmod -R 664 /var/www/
    3. sudo usermod -aG www-data pi


    hat jetzt genau so viel gebracht, dass ich den html Ordener nicht mehr mit Filezilla sehen kann (nur noch perr SSH/terminal console). Auch per Browser kann ich darin enthaltenen Daten nicht mehr aufrufen. Obwohl ich sie halt per terminal sehen kann.


    Wie kann ich den Ordner wider sehen, die Daten per Browser wieder aufrufen und endlich Dateien darin bearbeiten ?


    Danke für die Hilfe.

  • Hallo Wolly !


    Wenn ein Befehl nichts gebracht hat, musst Du den Urspungzustand wiederherstellen. Sonst machst Du das Admin-Dilemma immer schlimmer.


    Es har schon seinen Grund, warum alles ab /var/www www-data www-data gehört. Stelle zuerst einmal alle Dateien wieder auf www-data www-data zurück - mit chown lt. Zeile 1 #1


    Und dann ändere alle Dateiverzeichnisse auf 775 und alle Dateien auf 664.


    Die Datei, die der user pi in var/www/html bearbeiten dürfen soll kannst Du mit < setfacl u:pi:wr /var/www/html/Datei > mit einer ACL versehen.


    Siehe < man acl > < man getfacl > < man setfacl >



    Servus !:-

  • Dann entstehen in /var/www/html/ aber root-Dateien, was das Rechtedilemma eigentlich verschlimmert.


    Servus !

    Nicht, wenn er "chown -R www-data:www-data /var/www" danach macht. Mit Anmeldung "Pi" wäre es das gleiche Problem, da gehören die Files nämlich "Pi".


    Aber mit Pi würde er ja gar nicht erst soweit kommen, da das Verzeichnis www-data gehört. Da geht dann eh nix. Und 775 sollte man auch besser vermeiden.


    Und www-data hat kein SSH-Login.

  • Mit Anmeldung "Pi" wäre es das gleiche Problem, da gehören die Files nämlich "Pi".



    Wenn der User pi in die ACL eingetragen ist, wird die Datei als www-data erstellt/geändert/gelöscht.


    Das Ausführungs-Bit (--x) hat in Dateiverzeichnissen eine andere Bedeutung, als bei normalen Dateien.


    chmod -R ändert aber alle Dateien und Dateiverzeichnisse, sodass der TO seine Dateien nicht mehr sehen kannm weil das --x Bit bei den Dateiverzeichnissen fehlt und niemand mehr die Dateiverzeichnisse "betreten" (=auflisten) kann.


    Was ist an 775 verpönt ? INHO ist das die Grundeinstellung für Dateiverzeichnisse ( rwx rwx r-x) im LinuxHome Bereich.



    Servus !

  • Das ist dann alles wahrscheinlich schon eine Glaubensfrage...


    Ich habe mir angewöhnt, sämtliche Rechte nur www-data zu geben. Alles, was ich reinschiebe, bekommt chown -R www-data. Dem User Pi würde ich solche Berechtigungen nicht geben. Aber das kann natürlich jeder halten, wie er will.

  • Was ist an 775 verpönt ? INHO ist das die Grundeinstellung für Dateiverzeichnisse ( rwx rwx r-x) im LinuxHome Bereich.

    Das hängt u.a. davon ab, ob User Private Groups(UPG) bzw. User Groups (siehe /etc/adduser.conf) genutzt werden oder nicht. Siehe auch https://wiki.debian.org/UserPrivateGroups#How_It_Works

  • Sorry, habe mich vertan. Die Voreinstellung der Verzeichnsse ist 755 (rwx r-x r-x), von /bin bis /var, Ausnahme /tmp.


    Das Schreibrecht in /var/www/html hat aber mit der Group-Id des users pi (gid=1000 UPG) nicht worklich viel zu tun.



    Servus !

  • Wo ist denn auf einem System mit nur einem (non-system) User das Problem?

    DocRoot (/var/www/html) wird pi:www-data, 2755 (umask 0022 vorausgesetzt) und nur Verzeichnisse/Dateien für die der Webserver (www-data:www-data) wirklich Schreibzugriff benötigt bekommen g+w.

    So hat der User "pi" vollen Zugriff, ein evtl. kompromittierter Webserver aber nur bedingtes Schadenspotenzial. Da brauchts kein ACL etc. pp.