Keywords: main

Subsections

- A.1 Patch für den Source-Code von Mini SQL 2.0
- A.2 Patch für den Source-Code von W3-Auth
- A.3 Patch für den Source-Code von PHP/FI 2b12
  - Syntax von pg_sconnect()
- A.4 Shell-Script für automatischen Start von Apache 1.2 beim Booten
- A.5 Shell-Script für automatischen Start von mSQL 2.0 beim Booten
- A.6 Shell-Script für automatischen Start von PostgreSQL 6.2 beim Booten

# A Shell-Scripten und Patches

# A.1 Patch für den Source-Code von Mini SQL 2.0

Wie bereits in Kapitel 4.1.1.3 (S. ) 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:

- w3-msql.c
- config.c

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. ).

# A.2 Patch für den Source-Code von W3-Auth

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.

# A.3 Patch für den Source-Code von PHP/FI 2b12

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.

### Syntax von pg_sconnect()

`pg_sconnect(host, port, database, username, password)`

- [ host ]übergibt wie bei pg_connect() den zu kontaktierenden Host
- [ port ]übergibt den Post über welchen das DBMS kontaktiert werden soll.
- [ database ]gibt die Datenbank an, welche das DBMS öffnen soll.
- [ username ]teilt dem DBMS den Benutzernamen mit.
- [ password ]teilt dem DBMS das entsprechende Passwort mit.

Bei der Verwendung von pg_sconnect() sollte jedoch noch folgendes unbedingt beachtet werden.

- alle Übergabeparameter müssen belegt sein, sonst hagelt es Fehlermeldungen !!
- für jeden Datenbank-User muß eine eigene Passwortdatei angelegt werden.
- jede Datenbank eines Benutzers muß mit dieser Datei geschützt werden.
- jeder Benutzer, der auf eine geschützte Datenbank über PHP/FI zugreift, muß seine *.phtml Dateien vor unberechtigten Zugriffen anderer schützen (Lese- und Schreibschutz !!!), weil in diesen Dateien das Passwort in unverschlüsselter Form steht.
  Dies ist zwar nicht schön, ließ sich aber nicht vermeiden.

Bei Beachtung dieser vier kleinen Regeln kann dann auch nichts mehr schiefgehen.

# A.4 Shell-Script für automatischen Start von Apache 1.2 beim Booten

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`

# A.5 Shell-Script für automatischen Start von mSQL 2.0 beim Booten

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`

# A.6 Shell-Script für automatischen Start von PostgreSQL 6.2 beim Booten

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`