opi: Sichtbarkeit von Quellcode im Browser (Sicherheit)

Hallo zusammen,

nun habe ich mal eine grundlegende Frage zu Quellcode, den man im
Browser sehen kann. Zum Beispiel den Quellcode eines Perlskripts.

Ist es möglich, den Quellcode jedes Skripts und jedes Moduls - sowie
die Inhalte der Skalare eines Skripts - zu sehen, die im Browser
aufgerufen werden können? Wenn ja, kann ich mich dagegen irgendwie
schützen?

Wenn nein, wie kann ich Pfade zu Konfigurationsdateien etc.
verbergen, die in meinen Skripts und Modulen genutzt werden?
Zum Beispiel nutze ich eine simple Datei, in der Benutzername und
Passwort abgelegt sind. Die Datei ist allerdings ausserhalb des
Bereichs abgelegt, der über den Browser erreichbar wäre.

Beispiel:

Meine Perlskripts liegen unter /anydir/web/cgi/ und /anydir/web/
ist in der httpd.conf freigegeben.

Alias /public/ /anydir/web/

<Directory /anydir/web/cgi/>
    Options +ExecCGI
    AllowOverride None
    Order deny,allow
    Allow from all
</Directory>

<Directory /anydir/web/css/>
    Options None
    AllowOverride None
    Order deny,allow
    Allow from all
</Directory>

... usw ...

Nun liest mein Loginskript "/anydir/web/cgi/login.cgi" die
Passwortdatei /anydir/auth/user.conf aus.

Der Pfad /anydir/auth/ ist natürlich nicht in der httpd.conf
freigegeben.

Könnte ein Besucher trotzdem die Datei einsehen?

Wenn Module nicht eingesehen werden können, wäre es dann besser,
wenn ich das Auslesen einer Datei einer Funktion in einem Modul
überlasse, als dem Skript selbst?

Greez,
opi

--
Selfcode: ie:( fl:( br:^ va:) ls:] fo:) rl:( n4:? ss:| de:] ch:? mo:|
  1. Hi,

    Ist es möglich, den Quellcode jedes Skripts und jedes Moduls - sowie
    die Inhalte der Skalare eines Skripts - zu sehen, die im Browser
    aufgerufen werden können? Wenn ja, kann ich mich dagegen irgendwie
    schützen?

    sicher - sofern es nicht ausgeführt wird (und sofern die Script-Ausführung nicht den Quellcode des Scripts erzeugt, versteht sich).

    Könnte ein Besucher trotzdem die Datei einsehen?

    Der Besucher kann *keine* Datei einsehen. In HTTP existiert keine Datei. Es gibt nur Ressourcen. Dateien kann der Besucher sehen, wenn er z.B. einen FTP-Zugang besitzt.

    Cheatah

    --
    X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
    X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
    X-Will-Answer-Email: No
    X-Please-Search-Archive-First: Absolutely Yes
    1. Hallo Cheatah,

      Der Besucher kann *keine* Datei einsehen. In HTTP existiert keine Datei.

      Aber in den Verzeichnissen, die über <Directory ... in der httpd.conf
      freigegeben sind.

      Es gibt nur Ressourcen. Dateien kann der Besucher sehen, wenn er z.B. einen FTP-Zugang besitzt.

      Der Browser kann den _Inhalt_ von Dateien anzeigen. Von was anderem
      war nicht die Rede.

      http://localhost/public/css/test.txt

      zeigt den Inhalt der Datei an, wenn sie existiert.

      Greez,
      opi

      --
      Selfcode: ie:( fl:( br:^ va:) ls:] fo:) rl:( n4:? ss:| de:] ch:? mo:|
      1. Hi,

        Der Besucher kann *keine* Datei einsehen. In HTTP existiert keine Datei.
        Aber in den Verzeichnissen, die über <Directory ... in der httpd.conf
        freigegeben sind.

        ja, der Server kennt Dateien. Der Client auch. HTTP nicht.

        Es gibt nur Ressourcen. Dateien kann der Besucher sehen, wenn er z.B. einen FTP-Zugang besitzt.
        Der Browser kann den _Inhalt_ von Dateien anzeigen.

        Nein, den Inhalt von Ressourcen. Diese liefert der Server.

        http://localhost/public/css/test.txt
        zeigt den Inhalt der Datei an, wenn sie existiert.

        Falsch. Es zeigt das an, was der Server mit dieser URI assoziiert und zurückliefert. Also beispielsweise eine (ver- und wieder ausgepackte) Datei, oder das Ergebnis einer Script-Ausführung. Was davon es ist, liegt außerhalb der Kenntnis oder gar Kontrolle des Client.

        Cheatah

        --
        X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
        X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
        X-Will-Answer-Email: No
        X-Please-Search-Archive-First: Absolutely Yes
        1. Hallo cheatah,

          Der Besucher kann *keine* Datei einsehen. In HTTP existiert keine Datei.
          Aber in den Verzeichnissen, die über <Directory ... in der httpd.conf
          freigegeben sind.

          ja, der Server kennt Dateien. Der Client auch. HTTP nicht.

          Es gibt nur Ressourcen. Dateien kann der Besucher sehen, wenn er z.B. einen FTP-Zugang besitzt.
          Der Browser kann den _Inhalt_ von Dateien anzeigen.

          Nein, den Inhalt von Ressourcen. Diese liefert der Server.

          du meinst, dass der Server den Dateiinhalt zum Browser schickt und
          dieser das zugeschickte anzeigt? Dann habe ich jetzt verstanden wie
          du es meinst.

          Für mich sieht man im Browser den Inhalt der Datei :-)

          Greez,
          opi

          --
          Selfcode: ie:( fl:( br:^ va:) ls:] fo:) rl:( n4:? ss:| de:] ch:? mo:|
          1. Hallo opi,

            du meinst, dass der Server den Dateiinhalt zum Browser schickt und
            dieser das zugeschickte anzeigt? Dann habe ich jetzt verstanden wie
            du es meinst.
            Für mich sieht man im Browser den Inhalt der Datei :-)

            Es sieht zumindest so aus. Tatsächlich weißt du aber gar nicht, ob eine Datei mit dem im Request angegebenen Namen überhaupt existiert.
            Der Server könnte die Anforderung ebensogut auf ein Script umgeleitet haben, das dynamisch etwas generiert, was im Browser wie eine Textdatei aussieht. Anhand dessen, was der Client "sieht", kannst du nur mutmaßen, aber keine sicheren Schlüsse ziehen.

            So long,

            Martin

            1. Hallo Martin,

              Es sieht zumindest so aus. Tatsächlich weißt du aber gar nicht ob eine Datei mit dem im Request angegebenen Namen überhaupt existiert.

              oh doch. Natürlich weiß ich das. Immerhin ist es eine Datei, die
              ich angelegt habe und das Verzeichnis in der httpd.conf über einen
              Alias und über <Directory... freigegeben habe ;-)

              Genau darum ging es mir. Wenn die Datei existiert. Wenn der Pfad
              in der httpd.conf freigegeben ist. Dann kann man den Inhalt der
              Datei im Browser sehen.

              Greez,
              opi

              --
              Selfcode: ie:( fl:( br:^ va:) ls:] fo:) rl:( n4:? ss:| de:] ch:? mo:|
  2. Hallo,

    Ist es möglich, den Quellcode jedes Skripts und jedes Moduls - sowie
    die Inhalte der Skalare eines Skripts - zu sehen, die im Browser
    aufgerufen werden können?

    Kommt darauf an. Wenn die Dateien allesamt außerhalb des Document-Root oder innerhalb von cgi-bin liegen, dann werden sie beim Aufruf ausgeführt und der Benutzer bekommt nur die Ausgabe der Dateien zu sehen, nicht jedoch die Dateien selbst. Wenn Du ein Perl-Script natürlich ins Document-Root kopierst und der Webserver nicht angewiesen ist, bspw. *.pl trotzdem auszuführen, dann wird's natürlich komplett an den Besucher übermittelt. Oder wenn Du's als .txt im Document-Root abspeicherst. Bei Modulen sieht's etwas anders aus, *.pm wird im Normalfall vom Webserver nicht ausgeführt (wozu auch?) - im cgi-bin-Verzeichnis (oder jeglichem anderen ScriptAlias) gibt's halt bei einer *.pm-Datei höchstens ein 403 Forbidden oder 500 Internal Server Error (je nach Konfigurationsdetails, ist aber im Prinzip egal, Zugriff kann nicht stattfinden), wenn's normal im Document-Root Verfügbar ist, wird die *.pm-Datei an den Client übermittelt und wenn's außerhalb des Document-Root liegt, interessiert das den Webserver nicht.

    Wenn ja, kann ich mich dagegen irgendwie schützen?

    Alle Module außerhalb des Document-Root lagern, alls Perl-Scripte nach /cgi-bin/ oder den Webserver anweisen, dass er *.pl immer ausführt.

    Wenn nein, wie kann ich Pfade zu Konfigurationsdateien etc.
    verbergen, die in meinen Skripts und Modulen genutzt werden?

    Für Konfigurationsdateien gilt das gleiche wie für Module: raus aus dem Document-Root; in ScriptAlias-Verzeichnissen schaden sie zwar nicht unbedingt, aber schön ist das nicht.

    Nun liest mein Loginskript "/anydir/web/cgi/login.cgi" die
    Passwortdatei /anydir/auth/user.conf aus.

    Der Pfad /anydir/auth/ ist natürlich nicht in der httpd.conf
    freigegeben.

    Könnte ein Besucher trotzdem die Datei einsehen?

    Über den Webserver alleine (sofern der keine Sicherheitslücke hat): nein. Über eine in Deinen Scripten vorhandene Sicherheitslücke: möglicherweise ja.

    Wenn Module nicht eingesehen werden können, wäre es dann besser,
    wenn ich das Auslesen einer Datei einer Funktion in einem Modul
    überlasse, als dem Skript selbst?

    Wenn Du's richtig anstellst, kriegt keiner Deinen serverseitigen Quellcode mit, von daher: pack die Funktionen/Klassen/sonstwas dorthin, wo sie Dir programmiertechnsich am sinnvollsten erscheinen. Die Dateien, die den Krempel enthalten, teilst Du in 2 Teile auf: solche, die über's Web aufgerufen werden sollen, die kommen nach /cgi-bin/ oder der Webserver wird angewiesen sie auch außerhalb von /cgi-bin/ auszuführen (dann ist der Quellcode nicht sichtbar), der Rest der Dateien kommt außerhalb des Document-Root, so dass der Webserver gar nicht dran denkt, sie ausführen zu wollen. Dann passiert auch nichts (seitens des Webservers).

    Viele Grüße,
    Christian

    1. Hallo Christian,

      Ist es möglich, den Quellcode jedes Skripts und jedes Moduls - sowie
      die Inhalte der Skalare eines Skripts - zu sehen, die im Browser
      aufgerufen werden können?

      Kommt darauf an. Wenn die Dateien allesamt außerhalb des Document-Root oder innerhalb von cgi-bin liegen

      ein Document-Root habe ich nicht freigegeben, da alles mit Perl
      realisiert ist. Dann wäre ich von dieser Seite aus schonmal sicher.

      Wenn ja, kann ich mich dagegen irgendwie schützen?

      Alle Module außerhalb des Document-Root lagern, alls Perl-Scripte nach /cgi-bin/ oder den Webserver anweisen, dass er *.pl immer ausführt.

      Das habe ich getan. Module, Konfigurationsdateien etc. liegen _alle_
      ausserhalb des /cgi-bin/ Bereichs.

      Wenn Module nicht eingesehen werden können, wäre es dann besser,
      wenn ich das Auslesen einer Datei einer Funktion in einem Modul
      überlasse, als dem Skript selbst?

      Wenn Du's richtig anstellst, kriegt keiner Deinen serverseitigen Quellcode mit

      Das heißt also, dass man den Inhalt eines Skripts nur sehen kann,
      wenn ich dummerweise meinen Webserver nicht richtig konfiguriert
      habe und *.cgi oder *.pl Skripts nicht ausgeführt werden? Ok!

      Sollte ich trotzdem das auslesen von Konfigurationsdateien auslagern?

      Ansonsten: danke für die Antwort! Supi!

      Greez,
      opi

      --
      Selfcode: ie:( fl:( br:^ va:) ls:] fo:) rl:( n4:? ss:| de:] ch:? mo:|
      1. Hallo,

        Das heißt also, dass man den Inhalt eines Skripts nur sehen kann,
        wenn ich dummerweise meinen Webserver nicht richtig konfiguriert
        habe und *.cgi oder *.pl Skripts nicht ausgeführt werden? Ok!

        Nach dem, was Du geschrieben hast: ja, genau das trifft zu.

        Sollte ich trotzdem das auslesen von Konfigurationsdateien auslagern?

        Aus Sicherheitsgründen? Nein. Oder anders gesagt: Stell Dir vor, jemand würde doch an den Code kommen - was würde er ihm nützen? An die Konfigurationsdateien käme er trotzdem nicht automatisch.

        Viele Grüße,
        Christian

        1. Hallo Christian,

          ich möchte nochmal 100% sicher sein.

          Folgende Verzeichnisstruktur habe ich:

          /anydir/web/cgi/
          /anydir/web/css/
          /anydir/web/img/
          /anydir/modules/
          /anydir/config/
          /anydir/auth/

          In meiner httpd.conf ist folgendes eingerichtet:

          Alias /public/ /anydir/web/

          <Directory /anydir/web/css/>
              Options None
              AllowOverride None
              Order deny,allow
              Allow from all
          </Directory>

          <Directory /anydir/web/cgi/>
              Options +ExecCGI
              AllowOverride None
              Order deny,allow
              Allow from all
          </Directory>

          <Directory /anydir/web/img/>
              Options None
              AllowOverride None
              Order deny,allow
              Allow from all
          </Directory>

          Niemand kann also auf modules, config und auth zugreifen. Richtig?

          Greez,
          opi

          --
          Selfcode: ie:( fl:( br:^ va:) ls:] fo:) rl:( n4:? ss:| de:] ch:? mo:|
          1. Hallo opi,

            Niemand kann also auf modules, config und auth zugreifen. Richtig?

            Wenn nicht irgendwo anders in der Webserverkonfiguration ein Alias oder DocumentRoot o.ä. definiert ist, was auf eines der drei Verzeichnisse oder ein übergeordnetes Verzeichnis zeigt und sofern nirgendwo ein Symlink auf eines der drei Verzeichnisse oder ein übergeordnetes Verezeichnis existiert oder die Optionen FollowSymLinks und SymLinksIfOwnerMatch aus sind: nein.

            Viele Grüße,
            Christian

  3. nun habe ich mal eine grundlegende Frage zu Quellcode, den man im
    Browser sehen kann. Zum Beispiel den Quellcode eines Perlskripts.

    grundsätzliches wurde ja schon gesagt.

    1. cgi Verzeichnisse geben keine Resource preis sondern führen Programme aus.

    2. du siehst keine Dateien!
    Sondern nur das was der Server ausliefert und selbst wenn es lediglich die Inhalte einer Datei sind wird dort mehr übermittelt.

    3. wenn du wirklich Angst um deine Daten hast, dann pack diese in ein Verzeichniss, dass der Server nicht ausliefert. Üblicherweise heißt das http  Verzeichniss www (bei meinem Hoster aber z.b. html) alles was darunter liegt ist per http nicht erreichbar. Das bietet dir einen gewissen Schutz, falls aus welchen Gründen auch immer die Serverkonfiguration ein cgi Verzeichniss nicht mehr parst.

    Struppi.

    1. Hallo Struppi,

      1. wenn du wirklich Angst um deine Daten hast, dann pack diese in ein Verzeichniss, dass der Server nicht ausliefert. Üblicherweise heißt das http  Verzeichniss www (bei meinem Hoster aber z.b. html) alles was darunter liegt ist per http nicht erreichbar. Das bietet dir einen gewissen Schutz, falls aus welchen Gründen auch immer die Serverkonfiguration ein cgi Verzeichniss nicht mehr parst.

      der Hoster bin ich selber. Ich habe ein kleines Tool entwickelt und
      den Browser als Interface missbraucht. Ich verwende keine Standard-
      pfade. Das Tool wird unter einem beliebigen Pfad installiert. Das
      kann /opt/ oder /usr/local/ oder /was_auch_immer/ sein. Eine eigene
      tool_name.conf zur Einbindung in die httpd.conf wird mitgeliefert.

      Mir war das nur schonmal aufgefallen, dass ich auf eine Seite im
      www geklickt habe und mir der Quellcode angezeigt wurde.

      Greez,
      opi

      --
      Selfcode: ie:( fl:( br:^ va:) ls:] fo:) rl:( n4:? ss:| de:] ch:? mo:|
        1. wenn du wirklich Angst um deine Daten hast, dann pack diese in ein Verzeichniss, dass der Server nicht ausliefert. Üblicherweise heißt das http  Verzeichniss www (bei meinem Hoster aber z.b. html) alles was darunter liegt ist per http nicht erreichbar. Das bietet dir einen gewissen Schutz, falls aus welchen Gründen auch immer die Serverkonfiguration ein cgi Verzeichniss nicht mehr parst.

        der Hoster bin ich selber. Ich habe ein kleines Tool entwickelt und
        den Browser als Interface missbraucht. Ich verwende keine Standard-
        pfade. Das Tool wird unter einem beliebigen Pfad installiert. Das
        kann /opt/ oder /usr/local/ oder /was_auch_immer/ sein. Eine eigene
        tool_name.conf zur Einbindung in die httpd.conf wird mitgeliefert.

        Naja, dann gibt es keine Möglichkeit.
        Wie gesagt du kannst unterhalb des Pfades (sofern das Perl darf) der von dem Server ausgeliefert wird, die Daten die nicht sichtbar sein sollen, installieren. Ich hab dort z.b. meine eigenen Module installiert auch wenn es nicht wirklich nötig ist.

        Struppi.

        1. Hallo,

          Naja, dann gibt es keine Möglichkeit.
          Wie gesagt du kannst unterhalb des Pfades (sofern das Perl darf) der von dem Server ausgeliefert wird, die Daten die nicht sichtbar sein sollen, installieren. Ich hab dort z.b. meine eigenen Module installiert auch wenn es nicht wirklich nötig ist.

          doch doch, genau das habe ich ja gemacht. Schau hier:

          https://forum.selfhtml.org/?t=117550&m=752953

          Greez,
          opi

          --
          Selfcode: ie:( fl:( br:^ va:) ls:] fo:) rl:( n4:? ss:| de:] ch:? mo:|
          1. doch doch, genau das habe ich ja gemacht. Schau hier:

            https://forum.selfhtml.org/?t=117550&m=752953

            stimmt, hatte ich nicht genau gelesen.

            Struppi.

        2. Hallo Struppi,

          Wie gesagt du kannst unterhalb des Pfades (sofern das Perl darf) der von dem Server ausgeliefert wird, die Daten die nicht sichtbar sein sollen, installieren.

          du meinst doch sicher "oberhalb"?
          Denn *unterhalb* des DocRoot stehen ja gerade die Dateien, die der Server ausliefert. Was nicht per HTTP erreichbar sein soll, müsste dann also in Verzeichnissen *oberhalb* oder in Verzeichniszweigen *neben* dem DocRoot stehen.

          So long,

          Martin

          1. Hallo Martin,

            du meinst doch sicher "oberhalb"?
            Denn *unterhalb* des DocRoot stehen ja gerade die Dateien, die der Server ausliefert. Was nicht per HTTP erreichbar sein soll, müsste dann also in Verzeichnissen *oberhalb* oder in Verzeichniszweigen *neben* dem DocRoot stehen.

            ist das wirklich so? Ich weiß es nicht, wenn aber eine Freigabe mit ...

            Alias /public/ /public/html/

            <Directory /public/html/dir1/>
                Options None
                AllowOverride None
                Order deny,allow
                Allow from all
            </Directory>

            erfolgt, können dann Ressource unter /public/html/dir1/dir2/
            eingesehen werden?

            Greez,
            opi

            --
            Selfcode: ie:( fl:( br:^ va:) ls:] fo:) rl:( n4:? ss:| de:] ch:? mo:|
            1. Hallo opi,

              ist das wirklich so? Ich weiß es nicht, wenn aber eine Freigabe mit ...
              [...]
              erfolgt, können dann Ressource unter /public/html/dir1/dir2/
              eingesehen werden?

              Selbstverständlich. Die Freigabe gilt automatisch für /public/html/dir1/ und alle untergeordneten Verzeichnisse, sofern für diese nicht gesonderte Einstellungen vorgenommen werden.

              Die grundsätzliche Logik ist ähnlich wie bei einer Netzwerkfreigabe unter Windows. Wenn du das Verzeichnis E:\User\Allgemein für den Zugriff im Netzwerk freigibst, gilt die Freigabe automatisch auch für E:\User\Allgemein\Max und E:\User\Allgemein\Moritz.

              So long,

              Martin

              1. Hallo Martin,

                Selbstverständlich. Die Freigabe gilt automatisch für /public/html/dir1/ und alle untergeordneten Verzeichnisse, sofern für diese nicht gesonderte Einstellungen vorgenommen werden.

                jo, ich habs mal ausprobiert und meine CSS-Datei einen Pfad tiefer
                verschoben und mein Skript angepasst. Das klappt. Gut zu wissen.

                Greez,
                opi

                --
                Selfcode: ie:( fl:( br:^ va:) ls:] fo:) rl:( n4:? ss:| de:] ch:? mo:|
          2. Wie gesagt du kannst unterhalb des Pfades (sofern das Perl darf) der von dem Server ausgeliefert wird, die Daten die nicht sichtbar sein sollen, installieren.

            du meinst doch sicher "oberhalb"?

            Kommt auf die Sichtweise an. Die Wurzel ist unterhalb, das wurzelverzeichniss ist / oder \

            Denn *unterhalb* des DocRoot stehen ja gerade die Dateien, die der Server ausliefert. Was nicht per HTTP erreichbar sein soll, müsste dann also in Verzeichnissen *oberhalb* oder in Verzeichniszweigen *neben* dem DocRoot stehen.

            vielleicht besser 'ausserhalb'

            Struppi.

            1. Hallo Struppi,

              du meinst doch sicher "oberhalb"?
              Kommt auf die Sichtweise an. Die Wurzel ist unterhalb, das wurzelverzeichniss ist / oder \

              ähm, ungewöhnliche Sichtweise bei einer Verzeichnishierarchie. Damit bekäme der populäre Begriff "Unterverzeichnis" eine ganz andere Bedeutung.

              Mit "Verzeichnis unterhalb" meint man doch meistens ein Verzeichnis, das einem anderen im Dateisystem untergeordnet ist. Zugegeben, dass "root", also die Wurzel, dann ganz oben ist, wirkt jetzt merkwürdig - wird aber in diesem Kontext allgemein so gehandhabt.

              vielleicht besser 'ausserhalb'

              Ja, darauf können wir uns wohl einigen. Der Begriff scheint mir "sicher".  ;-)
              So long,

              Martin

              1. du meinst doch sicher "oberhalb"?
                Kommt auf die Sichtweise an. Die Wurzel ist unterhalb, das wurzelverzeichniss ist / oder \

                ähm, ungewöhnliche Sichtweise bei einer Verzeichnishierarchie. Damit bekäme der populäre Begriff "Unterverzeichnis" eine ganz andere Bedeutung.

                Mit "Verzeichnis unterhalb" meint man doch meistens ein Verzeichnis, das einem anderen im Dateisystem untergeordnet ist. Zugegeben, dass "root", also die Wurzel, dann ganz oben ist, wirkt jetzt merkwürdig - wird aber in diesem Kontext allgemein so gehandhabt.

                Stimmt, so hab ich das jetzt nicht gesehen. Ich glaube aber ich hatte den Begriff verwendet, weil im Windows Explorer das Unterverzeichniss oberhalb ist ...?!?

                vielleicht besser 'ausserhalb'

                Ja, darauf können wir uns wohl einigen. Der Begriff scheint mir "sicher".  ;-)

                Zumindest in dem Kontext wäre damit die Frage geklärt ;-)

                Struppi.

                1. Hallo,

                  Ich glaube aber ich hatte den Begriff verwendet, weil im Windows Explorer das Unterverzeichniss oberhalb ist ...?!?

                  urgs... seit wann das denn?
                  Nö, das Unterverzeichnis steht auch im Windows Explorer immer unterhalb, und das Stammverzeichnis (root) ist oben:

                  C:\  +-Program Files
                   +-Tools
                   +-Windows
                     +-Browser               (nur schematisch)
                     +-Fonts
                     +-system32

                  Da ist doch z.B. "Fonts" als Unterverzeichnis von "Windows" eindeutig unterhalb, oder nicht?

                  Schönen Abend noch,

                  Martin

                  1. Hallo Martin,

                    urgs... seit wann das denn?
                    Nö, das Unterverzeichnis steht auch im Windows Explorer immer unterhalb, und das Stammverzeichnis (root) ist oben:

                    C:\   +-Eigene Dateien
                      +-Program Files
                      +-Tools
                      +-Windows
                        +-Browser               (nur schematisch)
                        +-Fonts
                        +-system32

                    Da ist doch z.B. "Fonts" als Unterverzeichnis von "Windows" eindeutig unterhalb, oder nicht?

                    es kann auch etwas verwirrend sein. Hier liegen die "Eigenen
                    Dateien" tatsächlich unterhalb von Windows. In der Ansicht aber
                    oberhalb :-)

                    Mit entsprechenden Links geht wäre das unter Linux/Unix natürlich
                    das genauso.

                    Greez,
                    opi

                    --
                    Selfcode: ie:( fl:( br:^ va:) ls:] fo:) rl:( n4:? ss:| de:] ch:? mo:|
                    1. Moin,

                      C:\   +-Eigene Dateien
                        +-Program Files
                        +-Tools
                        +-Windows
                          +-Browser               (nur schematisch)
                          +-Fonts
                          +-system32

                      Da ist doch z.B. "Fonts" als Unterverzeichnis von "Windows" eindeutig unterhalb, oder nicht?

                      eieiei - hier hast du wahrscheinlich etwas durcheinandergebracht. ;-)
                      So wie du es nun dargestellt hast, liegt "Eigene Dateien" direkt in C:, also oberhalb vom Windows-Verzeichnis. Das mag ja durchaus stimmen (mal abgesehen davon, dass dieses Sonderverzeichnis bei mir auf einem ganz anderen Laufwerk liegt). Was du wirklich meintest, war aber vermutlich das hier:

                      Desktop
                       +-\Rechnername
                         +-Eigene Dateien   <-- dieser Eintrag?
                         +-C:\    | +-Program Files
                         | +-Tools
                         | +-Windows
                         |   +-Browser               (nur schematisch)
                         |   +-Fonts
                         |   +-system32
                         |   +-...
                         +-D:\      +-...

                      Hier liegt "Eigene Dateien" sogar "oberhalb" von C:, genaugenommen sogar außerhalb des gesamten Dateisystems, weil wir hier virtuelle Ordner und physikalisch im Filesystem existierende Verzeichnisse durchmischen. Der Eintrag "Eigene Dateien" ist in dieser Darstellung genauso eine Täuschung wie die Pseudo-Ordner "Drucker" oder "Systemsteuerung", die ja auch keine echten Verzeichnisse im Filesystem sind.

                      Schönen Tag noch,

                      Martin

                      1. Hallo Martin,

                        Desktop
                        +-\Rechnername
                           +-Eigene Dateien   <-- dieser Eintrag?
                           +-C:\    | +-Program Files
                           | +-Tools
                           | +-Windows
                           |   +-Browser               (nur schematisch)
                           |   +-Fonts
                           |   +-system32
                           |   +-...
                           +-D:\      +-...

                        jetzt habe ich extra dafür mein Notebook neu gestartet - Linux down,
                        Windows up - um zu schauen, ob das tatsächlich so ist ... und es
                        ist so. Hatte das irgendwie anders in Erinnerung.

                        Kommt vermutlich daher, weil ich Windows noch sehr selten nutze :-)

                        Greez,
                        opi

                        --
                        Selfcode: ie:( fl:( br:^ va:) ls:] fo:) rl:( n4:? ss:| de:] ch:? mo:|
    2. hi,

      Üblicherweise heißt das http  Verzeichniss www (bei meinem Hoster aber z.b. html)
      alles was darunter liegt ist per http nicht erreichbar.

      ^^^^^^^^

      Du meinst "darüber" ;-)

      gruß,
      wahsaga

      --
      /voodoo.css:
      #GeorgeWBush { position:absolute; bottom:-6ft; }