hotti: SuExec und umask

hi,

SuExec ist ja ne feine Sache. D.h., mein Webserver läuft unter derselben id wie ich als FTP-User. Eigentlich müsste da ja auch die umask gleich sein, ist aber nicht, es ist so:

-- Datei per FTP auf den Server gebracht hat die Attribute 644,
-- Datei per HTTP (upload über den Webserver und ein CGI) auf den Server gebracht, hat die Attribute 600.

Was ich auch nicht verstehe, dieselbe Datei, die der Webserver mit 600 schreibt, ist im Browser nicht anzeigbar (403 Forbidden). Andererseits sind Dateien, die ich per HTTP hochlade für CGI-Prozesse mit 600 lesbar (und werden mit 700 auch ausgeführt).

Erbitte sachdienliche Hinweise,
Horst Schlemmerschnitte

--
(Name geändert)
  1. Hallo Rolf,

    ...mein Webserver läuft unter derselben id wie ich als FTP-User. Eigentlich müsste da ja auch die umask gleich sein...

    das ist ein Trugschluss. Generell wird der Wert für umask zum Kompilierzeitpunkt festgesetzt. Dies betrifft die configure-option --with-suexec-umask.

    Was ich auch nicht verstehe, dieselbe Datei, die der Webserver mit 600 schreibt, ist im Browser nicht anzeigbar (403 Forbidden). Andererseits sind Dateien, die ich per HTTP hochlade für CGI-Prozesse mit 600 lesbar (und werden mit 700 auch ausgeführt).

    Durch suexec werden CGI-Programme mit dem zur Kompilierung angegebenen User (configure-option --with-suexec-caller) ausgeführt. Ist dieser in Deinem Fall in UID und GID tatsächlich mit dem des Webservers identisch?

    Gruß aus Berlin!
    eddi

    1. Eddi,

      mein Lieber,

      Durch suexec werden CGI-Programme mit dem zur Kompilierung angegebenen User (configure-option --with-suexec-caller) ausgeführt. Ist dieser in Deinem Fall in UID und GID tatsächlich mit dem des Webservers identisch?

      Ich hab keine Ahnung. Würds aber gerne rauskriegen ;-)

      Ne Shell hab ich nicht, aber ich hab da ein CGI auf dem Server, da kann ich Kommandos eingeben und die Ausgabe im Browser verfolgen. Dann hab ich noch die FTP-Erweiterung am Windows-Commander.

      Was ich schonmal versucht habe auf dem Kommandozeilen-CGI:

      cat /etc/issue # kommt nix
      id             # kommt auch nix
      ls             # Ausgabe folgt
      chmod          # geht auch

      Hast Du noch ne Idee?

      --Rolf

      1. Re:

        Hast Du noch ne Idee?

        Hast Du eine Möglichkeit mit POSIX oder einem Adäquat get(e)id() und get(e)uid() zu nutzen?

        Gruß aus Berlin!
        eddi

        1. jupp;

          Hast Du eine Möglichkeit mit POSIX oder einem Adäquat get(e)id() und get(e)uid() zu nutzen?

          printf("getegid: %s\ngeteuid: %s\ngetgid: %s\ngetuid: %s \n", $(, $>, $), $<);

          getegid: 443 443
          geteuid: 1127
          getgid: 443 443
          getuid: 1127

          Sagt mir nicht viel (nüschd wirklich), habch was vergessen?

          --Rolf

          1. Re:

            Nun ist interessant, ob sich 443:1127 (UID:GID des Prozesses) mit dem User per FTP hochgeladener Dateien deckt. Aus Deinem Ausgangspost ist zu vermuten, dass diese nicht identisch ist. Andernfalls kann ich mir HTTP-Status 403 nicht erklären.

            Gruß aus Berlin!
            eddi

            1. Hi Eddi,

              Nun ist interessant, ob sich 443:1127 (UID:GID des Prozesses) mit dem User per FTP hochgeladener Dateien deckt. Aus Deinem Ausgangspost ist zu vermuten, dass diese nicht identisch ist. Andernfalls kann ich mir HTTP-Status 403 nicht erklären.

              Vielen Dank, hab wieder was dazugelernt. Den Rest überlasse ich meinem Provider und ich bleibe lieber bei meinen Routern u.a. Netzwerkzeugs ;-)

              Das eigentliche Problem: Falls ich mal was mit HTTP hochladen muss, weil FTP nicht verfügbar ist, muss ich danach auf die Kommandozeile (CGI) und chmod 644 eintippen. Aber das Hochladen mit HTTP ist eh nur für den Notfall gedacht und Tippen ist eigentlich auch nicht wirklich ein Problem solange ich noch 10 Finger habe und meine Brille finde.

              Viele Grüße,
              Rolf

              --
              die; # das geht immer bei der Script
    2. Durch suexec werden CGI-Programme mit dem zur Kompilierung angegebenen User (configure-option --with-suexec-caller) ausgeführt.

      Ich habe das getestet und nachgelesen. Es ist falsch. Via suexec ausgeführte Programme bekommen die Rechten, die durch SuexecUserGroup festgelegt sind. Das wäre vielleicht für den Provider ein hilfreicher Hinweis, dort sich mal umzusehen.

      Durch --with-suexec-caller wird nur der User des Webservers einkompiliert.

      Gruß aus Berlin!
      eddi

      1. Hi Danke Eddi;

        Durch suexec werden CGI-Programme mit dem zur Kompilierung angegebenen User (configure-option --with-suexec-caller) ausgeführt.

        Ich habe das getestet und nachgelesen. Es ist falsch. Via suexec ausgeführte Programme bekommen die Rechten, die durch SuexecUserGroup festgelegt sind. Das wäre vielleicht für den Provider ein hilfreicher Hinweis, dort sich mal umzusehen.

        Ne, wenn alles läuft, lasse ich den in Ruhe ;-)

        Hotti

        --
        Das Posting wurde 953 mal als fachlich hilfreich bewertet.
        1. Hallo hotti.

          Das Posting wurde 953 mal als fachlich hilfreich bewertet.

          Ähm…?

          Servus,
          Flo

  2. Hi hotti,

    SuExec ist ja ne feine Sache. D.h., mein Webserver läuft unter derselben id wie ich als FTP-User. Eigentlich müsste da ja auch die umask gleich sein, […]

    Nein, muss sie nicht. Die umask ist nicht grundsätzlich per User festgelegt, sondern jeder Prozess kann sich die umask nach belieben ändern. Das geht in Perl, wie auch in PHP. Standardmäßig arbeitet ein Prozess meines Wissens nach mit der umask seines Elternprozesses, also des Prozesses, der ihn gestartet hat.

    Wenn du eine Datei über CGI (Perl?) hochlädst, dann wird diese CGI-Prozess vom Apache (bzw. allg. Webserver) gestartet. Ich könnte mir denken, dass der Apache sich selber eine restriktivere umask setzt, welche sich dann eben auch auf die ausgeführten CGI-Prozesse auswirkt. Gut vorstellbar wäre allerdings auch, dass SuExec aus Sicherheitsgründen für alle Prozesse die es ausführt eine restriktive umask setzt - das würde auch gut zum Security Model „Is the directory/target NOT writable by anyone else?” passen.

    Kurz um: Verschiedene umasks für verschiedene Prozesse sind keineswegs verwunderlich.

    Was ich auch nicht verstehe, dieselbe Datei, die der Webserver mit 600 schreibt, ist im Browser nicht anzeigbar (403 Forbidden). Andererseits sind Dateien, die ich per HTTP hochlade für CGI-Prozesse mit 600 lesbar (und werden mit 700 auch ausgeführt).

    Das ist relativ simpel, für eine Datei welche der Apache direkt ausliefert, kommt SuExec gar nicht zum Einsatz. SuExec ist (nur) dafür gedacht, CGI-Scripte auszuführen, nicht jedosch statische Inhalte auszuliefern.

    Wenn du nun also eine Datei hast, welche im Bezug auf User und Gruppe dir gehört und die Rechte 600 besitzt, kann der Apache die Datei schlicht und einfach nicht lesen. Selbiges gilt natürlich auch für Ordner, probier doch mal, einem dir gehörenden Ordner die Rechte für Gruppe und Welt zu entziehen (700) - Apache wird dir dann keine Inhalte dieses Ordners mehr ausliefern können.

    Anders, wenn Apache ein CGI-Script ausführt. In dem Fall wechselt Apache zum konfigurierten User (dir) und führt das Script dann unter deiner Benutzerkennung aus. Damit können dann natürlich auch Dateien mit den Rechten 600 gelesen werden. Dass ein Script mit 700 ausgeführt wird, liegt übrigens auch nur daran, dass der Ornder in dem das Script liegt sicherlich nicht 700 hat, denn sonst könnte Apache die hier genannten Bedingungen gar nicht prüfen.

    Viele Grüße,
      ~ Dennis.

    1. [..]

      Viele Grüße,
        ~ Dennis.

      Vielen Dank für die umfangreichen Info's, Dennis!!!

      Hotte

      --
      bmi liest mit.