nicht angemeldet
Dateien ausserhalbs des WWW-Verzeichnisses
0 0 0
Dateien ausserhalbs des WWW-Verzeichnisses
AugeHallo liebe selfHTML'ler,
entschuldigt bitte meinen Betreff, der nicht wirklich aussagekräftig ist.
Ich versuche euch meine Frage mal zu erläutern:
Auf meinem (Shared) Server habe ich in erster Distanz diverse Ordner,
aber nur die Dateien im Verzeichnis "WWW" sind Teil der Website.
Ich habe mal gehört, dass man auch Dateien außerhalb dieses Verzeichnisses speichern kann,
die aber trotzdem (z.B. durch PHP) geladen werden können.
Den Vorteil dieser Methode (ein direktes Laden durch den Benutzer ist nicht möglich)
würde ich jetzt auch gerne für meine Zwecke nutzen.
Allerdings habe ich keine Ahnung, wie der Pfad zu einer solchen Datei aussehen soll.
Das Wurzelverzeichnnis für den Internet-Auftritt ist doch der Ordner "WWW"...
Kann mir jemand weiterhelfen?
Danke schonmal für euere Bemühungen.
Viele Grüße
OLZU
-
Hallo,
Das Wurzelverzeichnnis für den Internet-Auftritt ist doch der Ordner "WWW"...
Ja, das Wurzelverzeichnis des Internet-Auftritts, aber nicht das Wurzelverzeichnis des Servers, dass dich in diesem Fall mehr interessieren dürfte.
Auf meinem Webspace ist es bspw so, dass ich immer 2 Verzeichnisse unterhalb des Internet-Roots eingeloggt werden, wodurch ich hier genügeng Möglichkeiten für .htpasswd-Dateien o.ä habe.
Den dazugehörigen Pfad verrät dir dein Provider.Markus.
-
Hallo,
mittels des HTTP-Protokolls sollte es Dir normalerweise nicht möglich sein, direkt auf Dateien zuzugrei´fen, die außerhalöb deiner "Document Root" ~ "WWW-Verzeichnis" liegen.
Das sollte nur durch zusätzliche Dienste, wie z.B. SSI, PHP, PERL, ASP, usw möglich sein.
LG
Chris-
Hallo Chris!
mittels des HTTP-Protokolls sollte es Dir normalerweise nicht möglich sein, direkt auf Dateien zuzugrei´fen, die außerhalöb deiner "Document Root" ~ "WWW-Verzeichnis" liegen.
Das sollte nur durch zusätzliche Dienste, wie z.B. SSI, PHP, PERL, ASP, usw möglich sein.
Genau das will ich erreichen. Aber wie komme ich per PHP an diese Dateien?
Viele Grüße
OLZU-
Hallo OLZU,
Das sollte nur durch zusätzliche Dienste, wie z.B. SSI, PHP, PERL, ASP, usw möglich sein.
Genau das will ich erreichen. Aber wie komme ich per PHP an diese Dateien?
Je nachdem, wie Dein Webaccount eingerichtet ist, kannst Du auch auf Dateien und Ressourcen außerhalb Deiner Document Root zugreifen.
Um das beurteilen zu können, könntest Du hier mal (temporär) einen Link auf ein PHP-Script mit dem Inhalt
<?php
phpinfo();
?>innerhalb Deines Accounts geben.
Das sagt dann eigentlich schon fast alles über Deine Möglichkeiten mit PHP aus.LG
Chris-
Hallo Chris!
Um das beurteilen zu können, könntest Du hier mal (temporär) einen Link auf ein PHP-Script mit dem Inhalt
<?php
phpinfo();
?>
innerhalb Deines Accounts geben.Hier ist der Link:
http://www.zubrod.de/info.phpWelche von diesen zahlreichen Angaben hilft mir jetzt weiter?
Danke für deine Hilfe.
Viele Grüße
OLZU-
hallo OLZU,
http://www.zubrod.de/info.php
Welche von diesen zahlreichen Angaben hilft mir jetzt weiter?Gar keine. Sehr ungewöhnlich ist außerdem die Angabe "Apache Version Microsoft-IIS/5.0".
Du hast noch nicht erklärt, _warum_ du solche Verrenkungen unternehmen willst. Es ist ein enormes Sicherheitsrisiko, auf Dateien außerhalb der DocumentRoot zugreifen zu wollen, kein vernünftiger Hoster wird dir das erlauben, da kannst du zappeln, wie du möchtest.
Es hat sich durchgesetzt, daß Hoster bei ihren Accounts eben auch Verzeichnisse wie "log", "phptmp", "backup" und ähnliches zur Verfügung stellen. Es hat doch Gründe, weshalb solche Verzeichnisse zwar über FTP und/oder SSL, nicht aber über HTTP erreichbar sind, gelle? Schau dir dazu einfach nochmal die AGB deines Providers an.Was du gern tun möchtest, ist in etwa dem Wunsch vergleichbar, im Supermarkt alle Kassen immer mit geöffnetem Geldfach für alle Kunden zum Zugriff anzubieten. Ein Supermarkt, der so vorgeht, ist in spätestens zwei Tagen pleite.
Also laß es einfach sein.
Grüße aus Berlin
Christoph S.
-
Moin!
Was du gern tun möchtest, ist in etwa dem Wunsch vergleichbar, im Supermarkt alle Kassen immer mit geöffnetem Geldfach für alle Kunden zum Zugriff anzubieten.
Nicht ganz. Er hat das doch in der Frage beschrieben und er scheint zu wissen, was da vorhat. Also:
Datei.php:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html lang="de"> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <title>Includieren von Inhalten außerhalb des Serverroots</title> <head> <body> <h1>Speicherbelegung (/proc/iomem)</h1> <pre> <?php <?php echo file_get_contents ('/proc/iomem'); ?> ?> </pre> </body> </html>Im wesentlichen ist es also ganz normales HTML. Innerhalb des HTML kann man php innerhalb von
<?php ... ?> einbinden (Alternative Kurzform: <? ... ?>
Hier wird einfach der file_get_contents() ausgeführt. Das bedeutet, php wird die Datei /proc/iomem im Document ausgeben. Die andere Variante - include - hat das "Problem", das darin befinlicher PHP-Code auch wieder ausgeführt wird. Das ist zum einen "overhead", zum anderen kann das gefährlich sein, zum Beispiel, weil jemand die Datei manipuliert.Eines noch: Damit die Datei gelesen werden kann ist es notwendig, dass "jeder" das Leserecht hat. Wer nicht weiss, was das bedeutet, der sollte dann aber wirklich die Finger von lassen. Insofern erübrigen sich Nachfragen, wie man dieses einstellt. Wer es nicht weiss, wie und vor allem WARUM Rechte verwendet werden, der lerne zuerst dieses.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
--
Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development-
Moin!
Datei.php:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="de">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>Includieren von Inhalten außerhalb des Serverroots</title>
<head>
<body>
<h1>Speicherbelegung (/proc/iomem)</h1>
<pre><?php
echo file_get_contents ('/proc/iomem');
?></pre>
</body>
</html>Natürlich... da war ein wenig zu viel PHP drin :)
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
--
Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development-
morgens fastix®,
Natürlich... da war ein wenig zu viel PHP drin :)
Null problemo ... ich bestreite ja nicht, daß man mit PHP (mit Perl übrigens auch, und auch noch mit anderen Techniken) über HTTP außerhalb der Documentroot herumfuhrwerken _kann_. Im Perl-Kapitel in SELFHTML haben wir übrigens bei solchen "systemkritischen" Beispielscripts kein Script zum Ausprobieren verlinkt - mit Bedacht.
Ich sehe den Sinn nicht ein, und es ist mir bisher nicht genügend dargelegt worden, warum es denn derlei Zugriff im öffentlichen Betrieb geben soll.Grüße aus Berlin
Christoph S.
-
Moin!
morgens fastix®,
Ich sehe den Sinn nicht ein, und es ist mir bisher nicht genügend dargelegt worden, warum es denn derlei Zugriff im öffentlichen Betrieb geben soll.Wo steht, dass er es veröffentlichen will? Könnte, neben tausenden anderen Gründen gut sein, er schützt das mit .htaccess. Stell Dir einfach vor, irgendjemand will einfach sehen oder zeigen, "wie es dem Server geht", wie lange er "online" ist etc. Natürlich: Dafür könnten die Daten noch gefiltert und in hübschere Formatierungen gepresst werden.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
--
Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development-
Hallo fastix®.
Stell Dir einfach vor, irgendjemand will einfach sehen oder zeigen, "wie es dem Server geht", wie lange er "online" ist etc.
Dafür könnte man unter Umständen auch http://example.org/server-status verwenden. (Sofern aktiviert und erwünscht.)
Natürlich: Dafür könnten die Daten noch gefiltert und in hübschere Formatierungen gepresst werden.
Dann bietet sich vielleicht php-sysinfo an.
(Nur um zwei vorgefertigte Lösungen zu nennen.)
Einen schönen Mittwoch noch.
Gruß, Ashura
--
sh:( fo:} ch:? rl:( br: n4:~ ie:{ mo:| va:) de:> zu:} fl:( ss:) ls:[ js:|
mathbr:del.icio.us/ mathbr:w00t/ -
hallo fastix®,
Stell Dir einfach vor, irgendjemand will einfach sehen oder zeigen, "wie es dem Server geht", wie lange er "online" ist etc. Natürlich: Dafür könnten die Daten noch gefiltert und in hübschere Formatierungen gepresst werden.
Seit einiger Zeit nehmen die Hoster dafür gerne Confixx. Das ist weiträumig konfdigurierbar. Viele haben auch den Webalizer laufen.
Grüße aus Berlin
Christoph S.
-
-
Hallo
Null problemo ... ich bestreite ja nicht, daß man mit PHP (mit Perl übrigens auch, und auch noch mit anderen Techniken) über HTTP außerhalb der Documentroot herumfuhrwerken _kann_.
Davon war garnicht die Rede. OLZU schrieb, er wolle Dateien per PHP einbinden, die außerhalb des, über HTTP zugänglichen, Verzeichnisses liegen. Diese sind innerhalb der document root, aber außerhalb der server root.
Abgesehen davon: Kann man mit PHP oder Perl _über HTTP_ wirklich außerhalb der server root agieren? Soweit ich informiert bin, funktioniert die Arbeit außerhalb der server root deshalb, weil auf die dortigen Resourcen über das Dateisystem zugegriffen wird, was rein garnichts mit HTTP zu tun hat.
Ich sehe den Sinn nicht ein, und es ist mir bisher nicht genügend dargelegt worden, warum es denn derlei Zugriff im öffentlichen Betrieb geben soll.
Das schrieb er mittlererweile in diesem Posting.
Tschö, Auge
--
Die Musik drückt aus, was nicht gesagt werden kann und worüber es unmöglich ist zu schweigen.
(Victor Hugo)
Veranstaltungsdatenbank Vdb 0.1-
Hallo Auge,
Abgesehen davon: Kann man mit PHP oder Perl _über HTTP_ wirklich außerhalb der server root agieren?
Was verstehst Du hier unter "Server Root"?
Die des Fileservers?
Die des Virtual Hosts?
Die des Primary HTTPD?
Oder ggf. die Rootshell des Users, wenn Dienste wie SUPHP o.ä. benutzt werden?HTTP kennt durchaus auch schreibende Methoden, solltest Du das mit "agieren" meinen. Aber auch diese können nur innerhalb der "Document Root" tätig werden. Die "Document Root" ist also der Teil des Dateisystems, der dem HTTPD maximal zur Verfügung steht für HTTP-Zugriffe. Dass der Daemon nun auch Logs schreiben darf oder seine Zusatzmodule auch anderswohin einen Kanal aufbeuen können (PHP, MySQL-API, usw), ist Sache dieser Zusatzmodule. Die arbeiten meistens unter dem Namen des Daemon-Users, und haben im (lokalen) Dateisystem dessen Rechte.
LG
Chris-
Hallo
Abgesehen davon: Kann man mit PHP oder Perl _über HTTP_ wirklich außerhalb der server root agieren?
Was verstehst Du hier unter "Server Root"?
[ ] Die des Fileservers?
[x] Die des Virtual Hosts?
[ ] Die des Primary HTTPD?Es geht mir um den Unterschied zwischen dem Zugriff über HTTP (Anforderung und Auslieferung der (HTML-)Datei und aller in ihr eingebundenen Ressourcen (Bilder u.Ä.)) und dem, was PHP oder Perl machen, die auch Dateien einlesen und ausführen können, die über HTTP nicht erreichbar sind.
Bei einem Hoster, auf dessen Server mehrere Kunden ihren Webspace haben, wird das ja oft so gemacht, dass ein (Unter)Verzeichnis (welches oft selbst festgelegt werden kann) dazu bestimmt ist, als Root für die Website zu fungieren (meine "server root"). Es gibt aber auch Verzeichnisse oberhalb oder neben diesem, die nur über das Dateisystem und FTP erreichbar sind. Dort können Dateien liegen, die vom Internet aus nicht erreichbar sein sollen. Halt so, wie es OLZU, meiner Meinung nach, durchaus nachvollziehbar beschrieben hat (Außer solcher Blüten wie "Distanz", womit er wohl eine Verzeichnisebene meint. :-)).
Nur wird sein Wunsch, dort liegende Dateien in eine HTML Seite zu laden, so wohl nicht machbar sein.
Tschö, Auge
--
Die Musik drückt aus, was nicht gesagt werden kann und worüber es unmöglich ist zu schweigen.
(Victor Hugo)
Veranstaltungsdatenbank Vdb 0.1-
Hallo Auge.
Nur wird sein Wunsch, dort liegende Dateien in eine HTML Seite zu laden, so wohl nicht machbar sein.
Ich könnte mir vorstellen, dass ein serverseitiges Script diese „Wrapper“-Funktion übernimmt.
Per mod_rewrite würde man davon nicht einmal etwas bemerken.Einen schönen Mittwoch noch.
Gruß, Ashura
--
sh:( fo:} ch:? rl:( br: n4:~ ie:{ mo:| va:) de:> zu:} fl:( ss:) ls:[ js:|
mathbr:del.icio.us/ mathbr:w00t/ -
Moin!
Bei einem Hoster, auf dessen Server mehrere Kunden ihren Webspace haben, wird das ja oft so gemacht, dass ein (Unter)Verzeichnis (welches oft selbst festgelegt werden kann) dazu bestimmt ist, als Root für die Website zu fungieren (meine "server root").
Die Bezeichnung "server root" ist dann falsch, du redest vom "document root".
Server-Root ist ein Verzeichnis des Apachen, zu dem relativ diverse Dateien abgelegt werden, wenn man in der Konfig keine absoluten Pfade angibt. Also z.B. die Konfigs, die Logfiles etc.
Es gibt darüber hinaus keine standardmäßig in den HTTP-Server integrierten Mechanismen, ausgeführte Programme am Zugriff auf das Dateisystem zu hindern. Es gelten die normalen Zugriffsrechte für den User, unter dem die Programme laufen.
Ich habe schon ein PHP-Skript geschrieben, welches ausgehend vom Dateisystem-Root / sämtliche Verzeichnisse auflisten und enthaltene Dateien editieren konnte - sofern die Dateisystemzugriffsrechte das erlaubt haben.
Das kann man nur einschränken, indem man die ausgeführten Programme z.B. in ein chroot-Jail einsperrt oder einen sehr eingeschränkten User mit suexec zuweist.
Es gibt aber auch Verzeichnisse oberhalb oder neben diesem, die nur über das Dateisystem und FTP erreichbar sind. Dort können Dateien liegen, die vom Internet aus nicht erreichbar sein sollen.
Sowas ist aber dann blödsinnig, wenn die Dateien dort nur lagern, damit ein "Kopierskript" sie dann letztendlich doch als HTTP-Daten verschickt.
- Sven Rautenberg
--
My sssignature, my preciousssss!-
Hallo
Bei einem Hoster, auf dessen Server mehrere Kunden ihren Webspace haben, wird das ja oft so gemacht, dass ein (Unter)Verzeichnis (welches oft selbst festgelegt werden kann) dazu bestimmt ist, als Root für die Website zu fungieren (meine "server root").
Die Bezeichnung "server root" ist dann falsch, du redest vom "document root".
Ok, wieder mal mit den falschen Begriffen um mich geschmissen.
Es gibt aber auch Verzeichnisse oberhalb oder neben diesem, die nur über das Dateisystem und FTP erreichbar sind. Dort können Dateien liegen, die vom Internet aus nicht erreichbar sein sollen.
Sowas ist aber dann blödsinnig, wenn die Dateien dort nur lagern, damit ein "Kopierskript" sie dann letztendlich doch als HTTP-Daten verschickt.
Klar. Um aber Dateien, die von Skripten auf der Website _verarbeitet_ werden, zu lagern[1], ist dies (einer) der richtige(n) Ort(e).
[1] Dateien, die bei Ausfall des Skriptinterpreters nicht einsehbar sein sollen z.B. eine config.php mit Zugangsdaten zu einer DB.
Tschö, Auge
--
Die Musik drückt aus, was nicht gesagt werden kann und worüber es unmöglich ist zu schweigen.
(Victor Hugo)
Veranstaltungsdatenbank Vdb 0.1
-
-
-
-
hallo,
Kann man mit PHP oder Perl _über HTTP_ wirklich außerhalb der server root agieren?
Von PHP weiß ich es nicht exakt, habe ich bisher nicht getestet. Mit Perl ist das durchaus möglich. "über HTTP" bedeutet ja lediglich, daß der Webserver eine Anforderung erhält, die er beispielsweise vom Perl-Interpreter ausführen läßt. Was der dann macht, interessiert den Webserver und dessen Konfiguration nur am Rande und ist von HTTP unabhängig. Das heißt, ein Perl-Script kann im Grunde genommen überall auf dem Server-Rechner etwas tun; auslesen, löschen, neu anlegen usw., und braucht sich um die Beschränkungen des Zugriffs, die der Webserver selbst hat, nicht zu kümmern.
Soweit ich informiert bin, funktioniert die Arbeit außerhalb der server root deshalb, weil auf die dortigen Resourcen über das Dateisystem zugegriffen wird, was rein garnichts mit HTTP zu tun hat.
Richtig. Was "auf dem Server" passiert, geschieht unabhängig von HTTP. Allerdings muß das Ergebnis an den Webserver zurückgereicht werden, damit der es in lesbarer Form an den aufrufenden Browser zurückschickt.
Grüße aus Berlin
Christoph S.
-
-
-
-
-
Hallo Christoph!
Du hast noch nicht erklärt, _warum_ du solche Verrenkungen unternehmen willst. Es ist ein enormes Sicherheitsrisiko, auf Dateien außerhalb der DocumentRoot zugreifen zu wollen, kein vernünftiger Hoster wird dir das erlauben, da kannst du zappeln, wie du möchtest.
Ich würde gerne per PHP MP3-Dateien laden/abspielen, auf die aber auf keinen Fall anders zugegriffen werden darf.
Man soll die Dateien also auf der Seite anhören können, aber ein direkter Zugriff/Download soll für den Besucher nicht möglich sein.
Mittlerweile glaube ich ja, dass ich mit Kanonen auf Spatzen schießen wollte.
Ein Schutz des richtigen Verzeichnisses per .htaccess sollte eigentlich auch ausreichen.
Ich werde dies heute Abend mal angehen.
Wer mir Arbeit ersparen will, darf mir aber auch gerne entsprechende Tipps geben... :-)Einen schönen Tag noch!
OLZU
-
Moin!
Ich würde gerne per PHP MP3-Dateien laden/abspielen, auf die aber auf keinen Fall anders zugegriffen werden darf.
Man soll die Dateien also auf der Seite anhören können, aber ein direkter Zugriff/Download soll für den Besucher nicht möglich sein.Das funktioniert sowieso nicht.
Entweder greift man direkt auf die Datei zu - oder man greift die Datei am Auslieferungsskript ab. In beiden Fällen sind die gesendeten Daten zwingend identisch.
Selbst reines Streaming mit richtigem Streaming-Server und Streaming-Client kann auf diese Weise nicht wirksam "eingeschlossen" werden - es gibt beispielsweise "passende" Soundkartentreiber, die allen digitalen Output direkt auf die Festplatte schreiben.
Ein Schutz des richtigen Verzeichnisses per .htaccess sollte eigentlich auch ausreichen.
Wer auf die MP3-Datei zugreifen kann, kann sie abspielen, egal welchen Mechanismus der Server dazu einsetzt, die Daten auszugeben.
Wenn du deine MP3s passwortschützt, kommt ohne Passwort niemand ran, und mit Passwort kann man sich die Dinger lokal abspeichern. Das ist eben so.
- Sven Rautenberg
--
My sssignature, my preciousssss!
-
-
Hallo,
http://www.zubrod.de/info.php
Welche von diesen zahlreichen Angaben hilft mir jetzt weiter?Gar keine. Sehr ungewöhnlich ist außerdem die Angabe "Apache Version Microsoft-IIS/5.0".
Unsinn!
open_basedir (novalue) ist hier, sollte es sich um einen Shared Host handeln, echt gemeingefährlich.
Und weitere Einstellungen ebenfalls.
Du kannst also lesen und schreiben, wo immer der PHP-Dienst Zugriff hat.LG
Chris -
Hallo Christoph,
Es ist ein enormes Sicherheitsrisiko, auf Dateien außerhalb der DocumentRoot zugreifen zu wollen, kein vernünftiger Hoster wird dir das erlauben, da kannst du zappeln, wie du möchtest.
Was bringt Dich darauf, das so absolut zu vermelden?
Jeder "ordentliche Hoster" stellt dem Kunden eine "Box" zur Verfügung, in der er sich austoben kann. Nur ein teil davon ist das öffentliche HTTP-Verzeichnis.
PHP kann von Haus aus ohnehin auf den gesamten loklen Host zugreifen. Die Einschränkungen müssen auf Server-Ebene oder, wenn dies nicht billig geht, eben spätestens auf Applikationsebene (PHP-Modul) vorgenommen werden.
Ich habe bisher noch nichts davon gelesen, dass die PHP-Einschänkungen nicht greifen würden, vorausgestzt natürlich, dass sie nicht widersprüchlich eingerichtet wurden.
LG
Chris
-
-
-
-
-
-
Tag,
Das Wurzelverzeichnnis für den Internet-Auftritt ist doch der Ordner "WWW"...
also ...
Angenommen parallel zu Deinem Verzeichnis "www" gibt es ein Verzeichnis "anderes"; in Deinem Verzeichnis "www" liegt ein "index.php" und in Deinem Verzeichnis "anderes" liegt eine Datei "mach_etwas.inc",
dann kannst Du die Datei "mach_etwas.inc" in Deinem "index.php" perinclude("../anderes/mach_etwas.inc");einbinden.
In der Verzeichnisstruktur könnte das wie folgt ausschauen.
8<---
c:\ c:\anderes\ c:\anderes\mach_etwas.inc
c:\www\ c:\www\index.php
8<---Grüße,
Steffen.-
Hallo Steffen!
dann kannst Du die Datei "mach_etwas.inc" in Deinem "index.php" per
include("../anderes/mach_etwas.inc");
> einbinden. Das hört sich so einfach und echt logisch an. Lieder funktionert dies mit meinen Tests auf die Schnelle überhaupt nicht. Vielleicht sollte jetzt einfach abbrechen und es morgen nochmal versuchen... Trotzdem vielen Dank! Viele Grüße OLZU-
Tag,
include("../anderes/mach_etwas.inc");
> > einbinden. Folgendes setze ich hinundwieder erfolgreich ein. ~~~php include($_SERVER["DOCUMENT_ROOT"] . "/../anderes/mach_etwas.inc");Das sollte eigentlich auf das gleiche wie oben hinauslaufen.
Ob es dafür noch andere PHP-/Server-Konfigurationen gibt weiß ich nicht. Bei mir hat es einfach so funktioniert.Grüße,
Steffen.
-
-
