nicht angemeldet
Member - Bereich inkl. Verzeichnisschutz
Hallo Zusammen
Ich mache mir schon seit längerem Gedanken, wie ich mein Online-Projekt schützen kann.
Ich habe mir schon einige Ansätze angeschaut, nur komme ich zu keiner gescheiten Lösung, welche alle Apsekte abdeckt.
Ich wäre froh, wenn ihr mir einen Ansatz geben könnt, wie ich meinen Bereich am Besten schützen kann.
Aspekte:
-
PHP Seiten im Memeber Bereich können nur abhängig von der Zugriffstufe aufgerufen werden (Dies spricht für eine Lösung mit PHP, MySQL und Sessions)
-
Die Verzeichnisse, in denen Dokumente (z.B. Bilder und PDFs) liegen, welche auf den Member-Seiten verlinkt sind, sollen auch nicht direkt aufgerufen werden können, falls einem die direkte URL bekannt ist. (Dies spricht wiederum für htaccess)
Ich weiss nicht recht, wie ich diese beiden Arten von Schutz mit einem gescheiten, sicheren Authentication - Script lösen kann.
Für Ratschläge, Lösungsansätze sowie Tutorials zum rein lesen bin ich Euch sehr dankbar.
Gruss
Pedro
-
Hallo Pedro,
- PHP Seiten im Memeber Bereich können nur abhängig von der Zugriffstufe aufgerufen werden (Dies spricht für eine Lösung mit PHP, MySQL und Sessions)
Ach ja? Das sehe ich völlig anders: http://httpd.apache.org/docs/mod/mod_auth.html
- Die Verzeichnisse, in denen Dokumente (z.B. Bilder und PDFs) liegen, welche auf den Member-Seiten verlinkt sind, sollen auch nicht direkt aufgerufen werden können, falls einem die direkte URL bekannt ist. (Dies spricht wiederum für htaccess)
Nichts spricht gegen servereigene Methoden, daher sehe ich nicht, warum Du mit einer DB arbeiten willst.
Überlege Dir ein Konzept für die Wartung der einzelnen .htaccess-Files mittels PHP und gleichfalls auch für eine Verzeichnisstruktur, die den gesezten Aspekten in ihrer Differenzierung von Zugriffsrechten gerecht wird.
Fragen? Frag!
Gruß aus Berlin!
eddi-
echo $begrueszung;
- PHP Seiten im Memeber Bereich können nur abhängig von der Zugriffstufe aufgerufen werden (Dies spricht für eine Lösung mit PHP, MySQL und Sessions)
Ach ja? Das sehe ich völlig anders: http://httpd.apache.org/docs/mod/mod_auth.html
Da es sich bei den "Members" um eine mehr oder weniger oft wechselnde Zusammenstellung handeln dürfte, halte ich es für keine besonders gute Idee, mit PHP in den Konfigurationsdateien des Apache zu schreiben.
Besser fände ich dann mod_auth_db oder mod_auth_dbm zu verwenden. Um diese DB-files zu bearbeiten gibt es für PHP die Database (dbm-style) Abstraction Layer Functions.Da aber auch das wieder auf Dateien im Zugriffsbereich des Apachen und auf Schreibrechte für selbige hinausläuft, zöge ich dann doch lieber die Verwendung von mod_auth_mysql in Erwägung.
echo "$verabschiedung $name";
-
Hallo dedlfix,
- PHP Seiten im Memeber Bereich können nur abhängig von der Zugriffstufe aufgerufen werden (Dies spricht für eine Lösung mit PHP, MySQL und Sessions)
Ach ja? Das sehe ich völlig anders: http://httpd.apache.org/docs/mod/mod_auth.html
Da es sich bei den "Members" um eine mehr oder weniger oft wechselnde Zusammenstellung handeln dürfte, halte ich es für keine besonders gute Idee, mit PHP in den Konfigurationsdateien des Apache zu schreiben.
begründe dies bitte, da ich aus dem schlichten Schlagwort keine Nachteile zu einer Datenbank sehe.
Gruß aus Berlin!
eddi-
echo $begrueszung;
- PHP Seiten im Memeber Bereich können nur abhängig von der Zugriffstufe aufgerufen werden (Dies spricht für eine Lösung mit PHP, MySQL und Sessions)
Ach ja? Das sehe ich völlig anders: http://httpd.apache.org/docs/mod/mod_auth.html
Da es sich bei den "Members" um eine mehr oder weniger oft wechselnde Zusammenstellung handeln dürfte, halte ich es für keine besonders gute Idee, mit PHP in den Konfigurationsdateien des Apache zu schreiben.
begründe dies bitte, da ich aus dem schlichten Schlagwort keine Nachteile zu einer Datenbank sehe.
Die hinzukommenden und wegfallenden User bedingen immer ein Neuschreiben der kompletten User-Datei und das muss dann auch noch mittels Schreibrecht für den Apachen (wenn PHP nicht gerade als CGI unter der Userkennung des Webspace-Besitzers läuft) erlaubt sein.
Die Nutzung einer DB trennt in meinen Augen die Zugriffe aus beiden Richtungen (Apache, Member-Administration) besser voneinander.
Ich weiß nicht, ob der Apache das file locking von PHP beachtet, um ein MySQL-Lock kommt er jedenfalls nicht herum.echo "$verabschiedung $name";
-
Hallo dedlfix,
- PHP Seiten im Memeber Bereich können nur abhängig von der Zugriffstufe aufgerufen werden (Dies spricht für eine Lösung mit PHP, MySQL und Sessions)
Ach ja? Das sehe ich völlig anders: http://httpd.apache.org/docs/mod/mod_auth.html
Da es sich bei den "Members" um eine mehr oder weniger oft wechselnde Zusammenstellung handeln dürfte, halte ich es für keine besonders gute Idee, mit PHP in den Konfigurationsdateien des Apache zu schreiben.
begründe dies bitte, da ich aus dem schlichten Schlagwort keine Nachteile zu einer Datenbank sehe.
Die hinzukommenden und wegfallenden User bedingen immer ein Neuschreiben der kompletten User-Datei und das muss dann auch noch mittels Schreibrecht für den Apachen (wenn PHP nicht gerade als CGI unter der Userkennung des Webspace-Besitzers läuft) erlaubt sein.
Der Server benötigt nur Leserechte, mehr nicht. Das Hilfsprogramm htpasswd läßt sich über einen Prozess mittels PHP bedienen. Dabei erstellt / ändert es Datein im Modus 0644.
Die Nutzung einer DB trennt in meinen Augen die Zugriffe aus beiden Richtungen (Apache, Member-Administration) besser voneinander.
Ich weiß nicht, ob der Apache das file locking von PHP beachtet, um ein MySQL-Lock kommt er jedenfalls nicht herum.In einer thread-gestützen Serveranwendung (MPM worker) auf reiserfs arbeitet flock() erwiesenermaßen nicht; leider. Ich habe in die Sourcen von htpasswd hineingeschaut. So wie ich es verstehe, wird dort kein expliziter Filelock ausgeführt. Vielmehr wird eine temporäre Datei erstellt, die dann an die Stelle der User-Datei "bewegt" wird.
Inwiefern dies Schwachstellen zu einer Datenbank auf einem blockorganisietem Gerät erzeut, weiß ich als Laie nicht.Gruß aus Berlin!
eddi-
echo $begrueszung;
Der Server benötigt nur Leserechte, mehr nicht. Das Hilfsprogramm htpasswd läßt sich über einen Prozess mittels PHP bedienen. Dabei erstellt / ändert es Datein im Modus 0644.
Und unter welchem User lässt PHP das htpasswd laufen?
echo "$verabschiedung $name";
-
echo $begrueszung;
Der Server benötigt nur Leserechte, mehr nicht. Das Hilfsprogramm htpasswd läßt sich über einen Prozess mittels PHP bedienen. Dabei erstellt / ändert es Datein im Modus 0644.
Und unter welchem User lässt PHP das htpasswd laufen?
Ich wiederhole: "Der Server benötigt nur Leserechte"
Was genau interessiert dort der User (der bei PHP als Handler User und Group des Servers und beim CGI dem angegebenen SuexecUserGroup entspricht)?
Die Passwort-Datei muß doch ohnehin ersteinmal vom Nutzer (per FTP/PHP) erstellt werden.Gruß aus Berlin!
eddi-
echo $begrueszung;
Der Server benötigt nur Leserechte, mehr nicht. Das Hilfsprogramm htpasswd läßt sich über einen Prozess mittels PHP bedienen. Dabei erstellt / ändert es Datein im Modus 0644.
Wo siehst du eigentlich den Unterschied, ob das CGI-PHP-Script die Schreibrechte hat oder der Server mit PHP-Modul?
Was genau interessiert dort der User (der bei PHP als Handler User und Group des Servers und beim CGI dem angegebenen SuexecUserGroup entspricht)?
Das ist jetzt deine Mutmaßung, dass das Ganze so wie du es eben beschrieben hast läuft. In dem Fall wäre das mit den Schreibrechten auch richtig.
Als PHP-Modul oder ohne SuexecUserGroup sieht das natürlich anders aus. Der OP hat nicht gesagt, was bei ihm/seinem Hoster läuft.Und die Sicherheitseinstellungen des Servers müssen auf das PHP-Skript, dass die Sicherheitseinstellungen des Servers ändert, wirken. Sonst könnte ja jeder kommen...
Anders ausgedrückt: Der Server muss auch das Script schützen, welches die Zugangsmodalitäten zu anderen Seiten des Projekts regelt. Und je nach Hierarchientiefe kann das zu einem verknüpften organisatorischen und Sicherheits-Problem werden.echo "$verabschiedung $name";
-
Re:
Der Server benötigt nur Leserechte, mehr nicht. Das Hilfsprogramm htpasswd läßt sich über einen Prozess mittels PHP bedienen. Dabei erstellt / ändert es Datein im Modus 0644.
Wo siehst du eigentlich den Unterschied, ob das CGI-PHP-Script die Schreibrechte hat oder der Server mit PHP-Modul?
Bezieht sich die Frage auf die unterschiedliche Handhabung der Dateirechte des Servers, so ist festzustellen, daß PHP als Handler leider die Rechte, die mit suexec gewechselt werden sollten, nicht wechselt, wie das beim CGI-Binär geschiht. In wiefern man mit einem kleinen Trick eine SSI-Konfigurationsanweisung ausnutzen kann, den Server doch zum wechseln zu nötigen, steht noch auf meiner Liste.
Was genau interessiert dort der User (der bei PHP als Handler User und Group des Servers und beim CGI dem angegebenen SuexecUserGroup entspricht)?
Das ist jetzt deine Mutmaßung, dass das Ganze so wie du es eben beschrieben hast läuft.
In dem Fall wäre das mit den Schreibrechten auch richtig.Ich setze das beschriebene Prozedere auch ein. Im Übrigen verstehe ich jetzt, was Du mit Schreibrechten meinst. Die Scripte werden ohne Ausnahme vom CGI-Binär ausgeführt, da dies wegen der oben angedeuteten "Rechteverletzung" des Moduls vermutlich auch vorwiegend in Shared-Hosting-Umgebungen eingesetzt wird.
Allgemein: Trete den Gegenbeweis an!
Als PHP-Modul oder ohne SuexecUserGroup sieht das natürlich anders aus. Der OP hat nicht gesagt, was bei ihm/seinem Hoster läuft.
Nur was die Schreibrechte angeht. Sicherheitsbedenken sehe ich bei vernünfiger Abschirmung durch Datei- und Verzeichnisrechte nicht. In dem Sinne kann eine detailierte Betrachtung, um welches SAPI es sich handelt, mangels Relevanz ausbleiben.
Und die Sicherheitseinstellungen des Servers müssen auf das PHP-Skript, dass die Sicherheitseinstellungen des Servers ändert, wirken. Sonst könnte ja jeder kommen...
Wovon um alles in der Welt redest Du? Die Sicherheitseinstellungen des Servers werden von PHP zu keiner Zeit berührt und es wird auch wie in Deinem ursprünglichen Post keine Serverkonfigurationsdatei manipuliert, es werden Daten, die zur HTTP-Authentifizierung herangezogen werden, geändert.
Anders ausgedrückt: Der Server muss auch das Script schützen, welches die Zugangsmodalitäten zu anderen Seiten des Projekts regelt. Und je nach Hierarchientiefe kann das zu einem verknüpften organisatorischen und Sicherheits-Problem werden.
Wiebitte? Wir reden hier von HTTP-Authentifizierung. Diese wird bis auf das Starten eines Prozesses, um htpasswd, oder von mir aus auch wie in Deinem Beispiel, um dbmmanage auszuführen, ausschlißlich vom Server geregelt. Warum sollte der Server das PHP-Script schützen, wenn es doch erreichbar sein muß, um Formulardaten zu validieren und gegebenenfalls htpasswd auszuführen?
Gruß aus Berlin!
eddi-
re eddi
Irgendwie verlieren wir uns im Kleinen und reden sicherlich auch teilweise aneinander vorbei. Wir wissen wenig zur genauen Situation des OP und unsere allgemeinen Herangehensweisen kommen nur nach und nach zum Vorschein. Deswegen stelle ich mal lieber meinen Gedankengang zu Problematik im Ganzen vor.
Ich denke, dass eine solche Struktur sinnvoll ist:
docroot-+-- allgemeiner Bereich
|
+-- Member-Bereich, geschützt
|
+-- (Moderatoren-Bereich, geschützt)
|
+-- Admin-Bereich, geschütztOb es einen Moderatoren-Bereich gibt, kommt auf die Größe der User-Gemeinde an. Ebenfalls ist zu erwägen, ob die Moderatoren eher Member mit Extra-Rechten (zur Userverwaltung) sind - dann ist evtl. kein Moderatoren-Bereich erforderlich - oder eher mehr Administratoren mit eingeschränkten Rechten.
Ähnliches gilt für den Admin-Bereich: Gibt es aufgrund der auszuführenden Aufgaben eigenständige Admin-Skripte oder werden dafür nur Member-Scripte mit ein paar mehr, an bestimmte Rechte gekoppelte Funktionen verwendet?
Wenn ich davon ausgehe, dass die Bereiche (und die Scripte) klar voneinander getrennt sind, wäre die folgende Konfiguration mein Favorit:
Die Anzahl der Administratoren ist ziemlich klein, Admins Auth-Daten sind im Admin-Verzeichnis "fest" in der .htuser[1] eingestellt. Kein Script kann daran was ändern. Für den Admin gibt es eigene Kennung für den Zugriff auf die Nutzdaten der Anwendung und die Userdaten in der DB.
Auth-Daten der Member werden in einem von den Admin-Auth-Daten getrennten System vorgehalten.
(Moderatoren-Auth-Daten werden entweder zusammen mit den Memberdaten verwaltet oder in einer getrennten Datenhaltung - je nach den oben erwähnten Erfordernissen.)
Nun kommt es auf die Größe der Gemeinschaft an, ob zur Verwaltung selbiger die Daten einfach (mit nicht vorhandenem(?) Lockingmechanismus) in Konfigurationsdateien geschrieben werden können und Konflikte bei konkurrierendem Zugriff ignoriert werden können, oder ob nicht eine "richtige" Datenbank dafür genutzt werden sollte. [2]
Mit getrennten Verzeichnissen (s.o.) und entsprechend fein eingestellten Zugriffsrechten auf die Tabellen/Felder der DB für die jeweiligen Admin/Moderatoren/...-Scripte bzw. für das Auth-Modul des Apachen stelle ich mir das sicherer und robuster vor.
dedlfix
P.S: Der ganze Gedankengang mit der DB ist natürlich dann hinfällig, wenn man keinen eigenen Server hat in dem man sich die entsprechenden Apache-Module einbinden kann.
[1] oder wie auch immer die genannt wird.
[2] Den DBM-Gedanken verwerfe ich wieder, der ist auch nicht besser als die htpasswd-Methode. Ich ging am Anfang davon aus, dass das PHP-Script direkt die .htuser-Datei bearbeitet wird (z.B. mit http://pear.php.net/manual/en/package.fileformats.file-passwd.php@File_Passwd_Authbasic). Apaches htpasswd ist da ja hoffentlich schneller mit Schreiben fertig, als es ein PHP-Script könnte.-
Irgendwie verlieren wir uns im Kleinen und reden sicherlich auch teilweise aneinander vorbei.
Nachdem ich hier nun schon lesen mußte, daß _ich_ hier mutmaße, bin _ich_ es sicher auch, der dafür verantwortlich ist.
Wir wissen wenig zur genauen Situation des OP und unsere allgemeinen Herangehensweisen kommen nur nach und nach zum Vorschein.
Die kann dahingestellt bleiden, da es um ein globales Problem geht.
Nun kommt es auf die Größe der Gemeinschaft an, ob zur Verwaltung selbiger die Daten einfach (mit nicht vorhandenem(?) Lockingmechanismus) in Konfigurationsdateien geschrieben werden können und Konflikte bei konkurrierendem Zugriff ignoriert werden können, oder ob nicht eine "richtige" Datenbank dafür genutzt werden sollte. [2]
Der zum Schreiben konkurierende Lesezugrif auf eine Datei .htusers birgt keinerlei Sicherheitsrisiken in sich, nur eine potentiell temporäre Einschränkung im Microsekundenbereich, die der Funktionalität zusetzten könnte. Eine detailierte Betrachtung, trotz Anmerkung, fand leider in diesem Punkt bis jetzt noch nicht statt.
Mit getrennten Verzeichnissen (s.o.) und entsprechend fein eingestellten Zugriffsrechten auf die Tabellen/Felder der DB für die jeweiligen Admin/Moderatoren/...-Scripte bzw. für das Auth-Modul des Apachen stelle ich mir das sicherer und robuster vor.
Ich bin ein zugegebener Datenbankmuffel und habe bis jetzt auch noch keine benötigt. Meine Tabellen sind Verzeichnisse. Diese sollen nach Deinem Vorschlag ohnehin angelegt werden. Ja muß ich diese Struktur dann auch noch extra in eine DB einmeiseln? Was kommt denn als nächstes? Das man "geschütze" Code-Schnipsel in eine DB schreibt und mit eval() sie zu aktivieren versucht? Hatten wir doch hier alles schon im Forum.
Diese fein eingestellten Zugriffsrechte auf die Tabellen, von denen Du schreibst, finden ihr Gleichnis in den einzelnen Verzeichnissen und denen dort abgelgeten .htaccess-Datein.
Es bedarf, ausgehend von Deinen Überlegungen, drei Verzeichnisse und vier Scripte:
/heim
|
|-/include
| |
| |-/member_data
| | | je nach Geschmack oder Anforderung
| |- [usw] hat Member ein Daten-"Blatt" oder | | ein Verzeichnis |-/scripte
| |
| |-/admin
| |
| |-/moderator
| |
| |-/member
| |
|-/sonstige | |-/auth | | | |-.htadmin | | | |-.htmoderator | | |-.htmember
|
-/htdocs | |-/sonstige\_web |-/schutzbereich
|
|-anmelde.php
|
|-admin
|
|-moderator
|
|-member
|
`-.htaccess/heim/htdocs/.htaccess
<Files admin>
AuthType Basic
AuthName "admin"
AuthUserFile /heim/auth/.htadmin
require valid-user
</Files>
<Files moderator>
AuthType Basic
AuthName "moderator"
AuthUserFile /heim/auth/.htmoderator
require valid-user
</Files>
<Files member>
AuthType Basic
AuthName "member"
AuthUserFile /heim/auth/.htmember
require valid-user
</Files>/heim/hrdocs/anmelde.php
if(alles_richtig($daten)) { shell_exec($pfad.'/htpasswd /heim/auth/.ht'.$gruppe.' '.$user.' '.$pass); }/heim/hrdocs/(admin|moderator|member)
# Das Script würde ich über PATH_INFO steuern, # (Bsp.: /member/susi/einstellungen/haarfarbe.html) # die User also virtuell halten und Daten aus # dem Verzeichnis /heim/include/member_data/$user # holen sowie Scripte aus /heim/include/scripte/$group $user =explode('/',$_SERVER["PATH_INFO"]); $user =$user[1]; $group=explode('/',$_SERVER["REQUEST_URI"]); $group=$group[2]; if($user!=$_SERVER["REMOTE_USER"]) { header('Status: 401'); exit; } # include der nach PATH_INFO und $group # erforderlichen Scripte und deren AbarbeitungIch wüßte nicht, was daran weniger "robust" ist.
Gruß aus Berlin!
eddi-
re
Ja muß ich diese Struktur dann auch noch extra in eine DB einmeiseln?
Nein, nicht extra. Dafür entfällt das .htmember / .htmoderator
Was kommt denn als nächstes? Das man "geschütze" Code-Schnipsel in eine DB schreibt und mit eval() sie zu aktivieren versucht?
Nein, bloß das nicht. Das soll doch eine Datenbank bleiben und keine Codebank werden. :-) Datenhaltung und Datenverarbeitung gehört getrennt. (ohne Smiley)
Diese fein eingestellten Zugriffsrechte auf die Tabellen, von denen Du schreibst, finden ihr Gleichnis in den einzelnen Verzeichnissen und denen dort abgelgeten .htaccess-Datein.
Ja.
/heim/hrdocs/anmelde.php
if(alles_richtig($daten))
{
shell_exec($pfad.'/htpasswd /heim/auth/.ht'.$gruppe.' '.$user.' '.$pass);
}Hier hätte ich eben Bedenken. Ein Script, das für alle drei Gruppen die Einträge vornimmt. Bringt es denn keine Vorteile sicherheitstechnischer Art, dies zu trennen? Und wie wäre es, die Admin-Kennungen gleich gar nicht über Webzugriffe sondern nur lokal zu verwalten? > Ich wüßte nicht, was daran weniger "robust" ist. Wie sieht es mit der Performance bei einer hohen User-Anzahl aus? Dies führt ja die Doku zu mod\_auth\_mysql als Vorteil an ("much quicker access"). dedlfix-
Moin Moin,
Hier hätte ich eben Bedenken. Ein Script, das für alle drei Gruppen die Einträge vornimmt. Bringt es denn keine Vorteile sicherheitstechnischer Art, dies zu trennen?
Das fasse ich so auf, daß die Bedenken aus dem Auslesen in einer Shared-Hosting-Umgebung herrühren. Da ist die Wahl des SAPIs sehr relevant:
Ist PHP das CGI-Binär, so ist die skizzierte Verzeichnisstruktur ausreichend. Die User-Datein werden automatisch mit den Schreibrechten des Web-Account-Inhabers erstellt - jedoch im Modus 0622 (jeder darf lesen). Im Beispiel muß also das Verzeichnis /heim/auth den Modus 0611 haben. Somit ist der gewählte Name der Datei quasi ein Passwort für andere Account-Inhaber auf der Maschine, da sie das Verzeichnis zwar öffnen Dürfen, es aber nicht auslesen können.
Ist PHP dem Server als Handler zur Seite gestellt, so hat jeder Account-Inhaber auf der Maschine durch die Rechte Severs automatisch auch Schreibzugriff auf die Datein. Es gilt also vorher abzuprüfen, ob der Hoster seine Hausaufgaben gemacht hat. Unerlässlich ist hier der Safe-Mode. Ist dieser nicht eingeschaltet, kann man auch hier mittels Verzeichnisnamen Angreifern das Leben versalzen:
Verzeichnisstruktur Modus Eigentümer
-------------------------------------------------
/heim - irrelevant -
|
-/auth 0711 Web-Inhaber |-/0JZfp8.E2RLAU 0711 Web-Inhaber
|
-/wZ40GcATzJkUI 0711 Web-Inhaber | |-.htadmin 0622 Server | |-.htmoderator 0622 Server |-.htmember 0622 ServerSelbstredend ist dies auch die beste Möglichkeit für das CGI (Sicherheitsmodel "paranoia").
Und wie wäre es, die Admin-Kennungen gleich gar nicht über Webzugriffe sondern nur lokal zu verwalten?
Das wäre m. E. einge Geschmackssacht. Der Superuser "Webinhaber" sollte natürlich auf Gegebenheiten auch ohne Scripte manuel eigreifen könnnen.
Ich wüßte nicht, was daran weniger "robust" ist.
Wie sieht es mit der Performance bei einer hohen User-Anzahl aus? Dies führt ja die Doku zu mod_auth_mysql als Vorteil an ("much quicker access").
Tests stehen Dir dazu frei, mich persönlich würde es auch interessieren. Allerdings ist bis jetzt die einhellige Meinung, daß Datenbanken eine Performancebremse sind. Nur hierbeit stellt sich dies nach logischen Gesichtpunkten absolut anders dar:
Mit Flat-Files muß der Server den gesamten File einlesen und sich einen einzigen Datensatz heraussuchen(, ein Caching kann nicht stattfinden) - bei der Datenbanklösung jedoch nicht. Hier ist nur die Betrachtung der permanenten aber geringen Resouceneinbuße eines weiteren Dienstes hinzunehmen und das System wird komplexer.
Wie sieht es hier mit einem Backup des Datenbestandes aus?
Unter welcher UID wird die Datei der DB geschrieben und in welchem Modus?
Wie hoch ist der globale Verlust des Servers beim servieren durch zuschalten des Moduls?
Gibt es Memoryleaks?Gruß aus Berlin!
eddi-
Fehlerkorrektur:
Ist PHP das CGI-Binär...
Schreibrechten des Web-Account-Inhabers erstellt - jedoch im Modus 0622 (jeder darf lesen).Der Modus muß 0722 sein, sonst ists mit dem Schreiben Essig ;)
PHP-Modul [...]
Verzeichnisstruktur Modus Eigentümer
/heim - irrelevant -
|
-/auth 0711 Web-Inhaber |-/0JZfp8.E2RLAU 0711 Web-Inhaber
|
`-/wZ40GcATzJkUI 0711 Web-Inhaber0777 (Server braucht
Schreibrechte)|
|-.htadmin 0622 Server
|
|-.htmoderator 0622 Server
|
`-.htmember 0622 Server-
Fehlerkorrektur der
Fehlerkorrektur:
Ist PHP das CGI-Binär...
Im Beispiel muß also das Verzeichnis /heim/auth den Modus 0611 haben.Der Modus muß 0711 sein, sonst ists mit dem Schreiben Essig ;)
-
-
-
-
-
-
-
-
-
- PHP Seiten im Memeber Bereich können nur abhängig von der Zugriffstufe aufgerufen werden (Dies spricht für eine Lösung mit PHP, MySQL und Sessions)
- PHP Seiten im Memeber Bereich können nur abhängig von der Zugriffstufe aufgerufen werden (Dies spricht für eine Lösung mit PHP, MySQL und Sessions)
- PHP Seiten im Memeber Bereich können nur abhängig von der Zugriffstufe aufgerufen werden (Dies spricht für eine Lösung mit PHP, MySQL und Sessions)