Wie bereits in Kapitel 4.1.1.3 (S. ![[*]](icons/cross_ref_motif.gif){kind=icon}
)
erwähnt, benutzt das
w3-msql Interface sogenannte
"Private Scripts", durch die verhindert wird, daß HTML-Dateien
nicht ohne das
w3-msql Interface geladen werden
können. Hierfür benötigt es aber einen "Private Script Pfad",
der sich außerhalb des normalen Web-Spaces befinden sollte.
Diesen Pfad bezieht
w3-msql standardmäßig über
die Datei
msql.conf (Kapitel 3.1.2.1,
Seite ). Es wird der Parameter
Inst_Dir
ausgelesen und an den dort angegebenen Pfad (z.B.
/soft/msql-2.0.1)
noch
/www angehängt. Der daraus resultieren
"Private Script Pfad" lautet dann
/soft/msql-2.0.1/www
und kann somit nicht verändert werden.
Das bedeutet, daß jeder User, der mit w3-msql und "Private Scripts" arbeiten will, Zugriff auf dieses Verzeichnis haben muß. Jedem Administrator ist es ein Dorn im Auge, in seinen Installationsverzeichnissen solche Zugriffe zu erlauben.
Daher kam die Idee einen konfigurierbaren "Private Script Pfad" einzuführen, der nach belieben änderbar ist. Es wurde dazu in der Datei msql.conf im Abschnitt [w3-msql] der Parameter Private_Dir hinzugefügt. Er gibt den Pfad, in dem die "Private Scripts" gefunden werden, an. Fehlt dieser Parameter, so wird automatisch der Wert des Parameters Inst_Dir genommen.
Damit nun w3-msql diesen neuen Parameter lesen kann, mußten folgende Dateien des Source-Code-Verzeichnisses von Mini SQL 2.0 geändert werden:
config.c
Sie befindet sich im Verzeichnis
./src/msql und
muß ab Zeile 58 um die Zeile
TT>
{"w3-msql", "private_dir", INST_DIR,
CHAR_TYPE, 0, 0},
erweitert werden.
w3-msql.c
ist im Verzeichnis
./src/w3-msql zu finden und
muß in Zeile 454 folgendermaßen geändert werden:
(char *)msqlGetCharConf("general","inst_dir"),
ändern in
(char *)msqlGetCharConf("w3-msql","private_dir"),
Jetzt kann der Source-Code neu kompiliert werden und die Datei
msql.conf
um den Parameter
Private_Dir erweitert
werden. Siehe dazu Kapitel 3.1.1 (S. ).
Beim Test des CGI-Programmes
w3-auth in Kapitel
4.1.5.2 (S. ) mußte ernüchternd festgestellt
werden, daß Areas
NICHT wie im Benutzerhandbuch
beschrieben zu einem bestimmten Namespace gehören. Demzufolge konnte
jeder Administrator eines Namespaces auch die Areas anderer Namespaces
einsehen und ändern. Es brach zwar nach unbefugtem Ändern einer Area
der ganze Authentifizierungs-Mechanismus zusammen (Zugriffe auf die
manipulierte Area waren von niemanden
mehr möglich !!) und war somit unbrauchbar, dennoch mußte eine Lösung
für das Problem gefunden werden. Die Auswirkungen, die ein solcher
Programmfehler auf das ganze System haben kann, dürften wohl jedem
bekannt sein.
Nach eingehender Analyse des Source-Code der Datei
w3-auth.c
konnte der Fehler schnell beseitigt werden. Grund dafür war ein vergessenes
SQL Kommando in Zeile 2199. In der dort befindlichen SELECT-Abfrage
fehlte ein
... WHERE namespace = '$curNS' ...
Nach dem Einfügen der fehlenden SQL-Sequenz und anschließendem Neu-Kompilieren
reagierte das CGI-Programm
w3-auth wie gewünscht.
Areas können jetzt nur innerhalb ihres zugeordneten Namespaces eingesehen und geändert werden.
Obwohl die ersten Versuche mit PHP/FI 2b12 und PostgreSQL 6.2 erfolgreich verliefen, stellte sich schon bald heraus, daß die Benutzer ein und desselben Web-Sapces auf alle Datenbanken über PHP/FI zugreifen können.
Das ist deshalb möglich , da der Datenbankzugriff über PHP/FI mit der Funktion pg_connect() durch den Web -Server erfolgt. Es muß also der User des Web-Servers (normalerweise 'nobody') als Datenbank-User eingetragen sein. Eine Unterscheidung verschiedener Benutzer ist deshalb nicht möglich.
Abhilfe für dieses Problem schien die Datei ./data/pg_hba.conf zu versprechen. In ihr können einzelne Datenbanken über verschiedene Weise zugriffsgeschützt werden. Eine dieser Methoden ist der Passwortschutz. Hierzu wird der entsprechenden Datenbank eine Passwortdatei zugeordnet. Zugriff haben dann nur noch eingetragene Datenbank-User mit gültigem Passwort.
Von Kommandozeilenebene funktionierte dies hervorragend. Beim Zugriff
über PHP/FI kamen jedoch statt der gewünschten Daten nur Fehlermeldungen.
Der Zugriff wurde nicht gestattet.
Nach längerem Überlegen gab es nur eine Lösung, dieses Problem zu
beheben. Eine neue PHP/FI Funktion mußte her.
pg_sconnect()- das 's' steht hierbei für
'secure';
also Sicherheitsverbindung.
Mit Hilfe dieser neuen Funktion war es dann möglich, auch auf passwortgeschützte
Datenbanken zuzugreifen. Dazu mußte nicht einmal mehr der Web Server
'nobody' als Datenbank User eingetragen sein.
Es genügt jetzt, wenn der mit
pg_sconnect() übergebene
Benutzer als Datenbank User eingetragen ist.
pg_sconnect(host, port, database, username, password)
Bei Beachtung dieser vier kleinen Regeln kann dann auch nichts mehr schiefgehen.
Das in Kapitel 2.1.1 (S. )
erwähnte Shell-Script sieht dann so aus:
#!/bin/sh
# init.d Script fuer den Web-Server Apache 1.2
##############################################
# die folgenden Variablen koennen entsprechend
# der Installation angepasst werden
apachehome=/soft/apache-1.2
wwwuser=nobody
killallwww=yes
pidfile=$apachehome/logs/httpd.pid
##############################################
# ab hier sollten keine Aenderungen mehr
# vorgenommen werden .......
case $1 in
start)
echo Start des Web-Server Apache 1.2 .....
cd $apachehome/bin
./httpd
echo OK .........
;;
*)
echo Stoppen des Web-Server Apache-1.2 .....
if [ -f $pidfile ] ; then
kill -USR1 'cat $pidfile' 2>/dev/null
sleep 4
kill 'cat $pidfile' 2>/dev/null
sleep 1
kill -9 'cat $pidfile' 2>/dev/null
fi
# beenden aller CGI-Scripten ....
if [ x$killallwww = xyes ] ; then
echo Beende alle Programme die als $wwwuser laufen
su $wwwuser -c "kill -9 -1"
fi
echo Apache-1.2 beendet ....
;;
esac
exit 0
Das folgende Shell-Script findet Verwendung in Kapitel 3.1.1
(S. ).
#!/bin/sh
# init.d Script for Mini SQL 2.0
#######################################################
# diese Variablen koennen entsprechend der Installation
# veraendert werden
msqlhome=/soft/msql-2.0.1
msqluser=msql
pidfile=$msqlhome/msql2d.pid
#######################################################
# in diesem Abschnitt sollte nihcts veraendrert werden
case $1 in
start)
echo Starte Mini SQL 2.0 .....
cd $msqlhome/bin
./msql2d &
echo OK ....
;;
*)
echo Beenden von Mini SQL 2.0 .....
if [ -f $pidfile ] ; then
kill -USR1 'cat $pidfile' 2>/dev/null
sleep 4
kill 'cat $pidfile' 2>/dev/null
sleep 1
kill -9 'cat $pidfile' 2>/dev/null
fi
echo Mini SQL 2.0 beendet ...
;;
esac
exit 0
Das folgende Shell-Script findet Verwendung in Kapitel 3.2.1
(S. ).
#!/bin/sh
# init.d Script for PostgreSQL 6.2
#######################################################
# diese Variablen koennen entsprechend der Installation
# veraendert werden
home=/soft/postgresql-6.2
user=postgres
#######################################################
# in diesem Abschnitt sollte nichts veraendrert werden
case $1 in
start)
sleep 10
echo Starte PostgreSQL .....
su postgres -c '/soft/bin/postmaster -D /soft/postgresql-6.2/data
-S'
echo OK ....
;;
*)
echo Beenden von PostgreSQL .....
su postgres -c 'kill -9 -1'
echo PostgreSQL beendet ...
;;
esac
exit 0
Christian Eibisch