Servlet und JSP verbinden

Kleine Exkursion in die Welt von JavaServerPages und Servlets und wie man dazwischen Daten austauschen kann. Zunächst mal die einfache Seite, die JSP :

<%@ page import="java.net.IDN,misc.*,web.*,java.util.*,rsi.*,hash.*,sendmail.Sendmail,java.io.*,server.*,org.json.JSONArray,org.json.JSONObject,ordb.Pandora_server" pageEncoding="UTF-8"
%><%@ include file="cookies.jsp"
%><jsp:useBean id="daten" scope="session" class="hash.StringHash"
/>

Der JSP:useBean Tag ermöglicht u.a. sessionbasierte Objekte in einer JSP zu verarbeiten. Überall wo man den Tag angibt, ist das Objekt verfügbar. Da kann man dann ganz normal drauf zugreifen und mit arbeiten.

if ( daten.checkContent() ) out.write("Daten wurden geprüft und für OK befunden");

Wenn nun ein zweiter Teil der Anwendung in einem Servlet geschrieben wurde,  möchte man ggf. Daten zwischen beiden Teilen der Anwendung austauschen. Ein Servlet ist nichts anderes als eine Klasse, deren vordefinierte Methoden das Request- und Responseobjekt des Webaufrufes bekommen.

Ein kleines, stark vereinfachtes Beispiel:

public class HTMLDispatcher extends HttpServlet {

public void doGet(HttpServletRequest req, HttpServletResponse res)
throws IOException {
    doRequest(req,res);
}

public void doPut(HttpServletRequest req, HttpServletResponse res)
throws IOException {
    doRequest(req,res);
}

public void doDelete(HttpServletRequest req, HttpServletResponse res)
throws IOException {
    doRequest(req,res);
}

public void doPost(HttpServletRequest req, HttpServletResponse res)
throws IOException {
    doRequest(req,res);
}

...
}

Das Servlet kann man dann im Tomcat ( WebApplicationServer ) als Ziel für verschiedene Webaufrüfe definieren (siehe unten). In meinem Fall habe ich gesagt, daß mein Servlet für HTML Aufrüfe zuständig ist. Mein Servlet wertet dann die URL aus und macht mit dem HTML File noch einiges, bevor es ausgegeben wird.

public void doRequest(HttpServletRequest request, HttpServletResponse res)
throws IOException {

res.setContentType("text/html");
Writer out = new BufferedWriter(new OutputStreamWriter(res.getOutputStream(), "UTF-8"));

String method = request.getMethod();
String uri = request.getRequestURI();
String[] args = uri.split("/",-1); // Alles splitten, auch wenn es leer ist

StringHash daten = (StringHash) request.getSession().getAttribute("daten");
if ( daten == null ) daten = new StringHash();

Um an die Daten aus der JSP zu kommen, setze ich „request.getSession().getAttribute(„daten“)“ ein. Das geht aber nur mit Sessionobjekten so. Da die Methode getAttribute() ein klassenloses Objekt zurück gibt, muß selbst den TypeCast machen. Wenn noch keine Session aufgebaut wurde, kann es auch noch kein Bean geben, das wir uns krallen könnten. Damit die Anwendung dann nicht abschmiert, lege ich hier ein Objekt an. Natürlich kann man an der Stelle auch eine Fehlermeldung oder einen Redirect auslösen. Das ist situationsabhängig.

O== Warum überhaupt Servlet und JSP mischen ?

Servlets müssen kompiliert und der WAS Server üblicherweise neu gestartet werden, um die Änderungen anzunehmen. Wenn man JSP Seiten benutzt kümmert sich Jasper darum. Das spart im Einzelfall eine Menge Zeit und man verliert dabei auch keine Sessionobjekte, d.h. kleinere Fehler kann man direkt beheben und weitermachen. Zweifelsfrei eine zeitsparende Methode seine Webseiten zu bauen.

O== Wofür setzt man ein Servlet ein ?

Servlets können auf spezielle Webanfragen eingestellt werden, d.b. bspw. alle Files die auf .jos enden, könnten eine serialisierte Repräsentation des JavaObjekts einer Seite ausgeben, statt HTML Code. Das bekommt man mit reinen JSP Seiten nicht hin.

O== Wie aktiviert man ein Servlet ?

Im WEB-INF Verzeichnis der Anwendung liegt die web.xml Datei. In dieser Datei kann man ein Servlet ganz leicht hinzufügen:

    <servlet>
        <servlet-name>HTMLDispatcher</servlet-name>
        <servlet-class>servlet.HTMLDispatcher</servlet-class>
    </servlet>

    <servlet-mapping>
        <servlet-name>HTMLDispatcher</servlet-name>
        <url-pattern>*.html</url-pattern>
    </servlet-mapping>

Die nötigen Klassen müssen dann im dortigen classes Verzeichnis hinterlegt sein.

Tip: Update der Inhalte eines SQL Views

In einer Datenbank wie MySQL kann man sich Selects als Pseudotabellen anlegen und dann selbst wieder über den diese Tabelle einen Select bauen. So etwas nennt man einen View.

Beispiel:

SELECT a.vorname,a.name,b.beruf as beruf FROM Personen as a,Berufe as b WHERE a.berufsid=b.id;

Wenn man diesen Select als View anlegt, hat man drei Felder : Vorname,Name,Beruf

Nennen wir den View mal Test, wäre dieser Select möglich :

SELECT vorname,name FROM Test WHERE beruf = „Bäcker“;

Wenn man nun versucht den VIEW mit UPDATE zu ändern, geht das eigentlich nicht, weil es eine nicht eindeutige Beziehung der Datensätze untereinander ist.

Für mein aktuelles Pandora Projekt habe ich nun einen View gebaut, bei dem das Update tatsächlich möglich ist:

select `pa`.`id` AS `id`,`pa`.`vorname` AS `vorname`,`pa`.`nachname` AS `nachname`,`pa`.`server` AS `server`,`pc`.`value` AS `friendmode` from (`pandora`.`pandora_config` `pc` join `pandora`.`pandora_account` `pa`) where ((`pa`.`id` = `pc`.`uid`) and (`pc`.`name` = ‚michsuchen‘))

Das funktioniert aufgrund dieser Beziehung „((`pa`.`id` = `pc`.`uid`)“ , denn in beiden Tabellen gibt es exakt einen eindeutigen Datensatz. d.b. :

Für jede Person gibt es exakt einen Config Eintrag in der anderen Tabelle. Damit kann der Datenbankserver jetzt die logische Verbindung der Datensätze „rückwärts“ auflösen und in der richtigen Tabelle den richtigen Eintrag ändern:

UPDATE `pandora_userliste` SET friendmode = ‚erlauben‘ WHERE vorname =’meinvorname‘;

Damit ist der View Read/Writeable geworden was es man mit Hilfe des ORDB Frameworks ausnutzen kann, denn Views werden ein Java Datenobjekte erzeugt. Über Views lassen sich schlanke Strukturen und Datenbankobjekte erzeugen, die dazu noch updatefähig sein können (aber nicht müssen). Als Folge davon erhält man übersichtliche Datenbankstrukturen, die von einem Menschen leicht gelesen und verstanden werden können, aber trotzdem Datenbanktechnisch höchst performant gestaltet sein können.

Probleme mit SELinux reparieren

SELinux mal wieder mal um die Ohren geflogen? Vielleicht kann dieser Artikel helfen.

Es war einmal eine neue SSD …

Vor einigen Tagen habe ich meine Systemfestplatte durch eine SSD ersetzt. Da die ganze Platte verschlüsselt war, folgte ein ziemlich aufwändiger Prozess um die Inhalte zu kopieren. Dabei wurde SELinux allerdings vergessen, was dazu geführt hat, daß Linux danach nicht mehr ganz störungsfrei lief.

Alles in allem häuften sich Meldungen wie diese :

Mar 22 23:10:48 eve python: SELinux is preventing /usr/lib64/firefox/plugin-container from open access on the file .

Da stellt sich einem Admin erstmal die Frage, welches File er da nicht öffnen konnte und wieso nicht. Leider bleibt diese Frage unbeantwortet, da das Audit von SELinux dazu schweigt. Dummerweise weiss man nicht welche Datei gemeint ist und was falsch sein könnte. Solange mein Bugreport nicht zu einer Änderung führt, werden wir das auch nie erfahren, da nicht mal strace herausfindet, welche Datei gemeint ist.

Wie Anfangs schon erwäht, wurden Daten von einer Platte auf eine andere kopiert und letztlich war das das Problem.

Was macht SELinux ?

SELinux (ab jetzt nur SEL ) kennt für fast jede Datei einen Zugriffscontext, fcontext genannt. Mit einem ls sieht man diesen Context nicht gleich, dazu muß man die -Z Option benutzen :

# ls -lad /home/
drwxr-xr-x. 4 root root 4096 20. Mär 07:03 /home/

# ls -ladZ /home/
drwxr-xr-x. root root system_u:object_r:home_root_t:s0 /home/

Das Verzeichnis /home/ hat also als Defaultcontext „home_root_t“ ( die enden fast alle auf _t, nicht fragen ). Alle Dateien in /home/ bekommen auch erstmal diesen Context. Programm die in einem Context gestartet wurden, können erstmal nicht auf Dateien in einem anderen Context zugreifen. Das verhindert, daß man durch den Hack z.b. des Apache Webservers auf systemrelevante Dateien zugreifen kann, auch wenn man durch den Hack Rootuser geworden ist. An sich eine Supersache was Security angeht.

Damit das klappt gibt es unter „/etc/selinux/targeted/contexts/files“ eine Liste mit Contexten, die Dateien zugeordnet sind. Wenn man jetzt TAR benutzt um den Inhalt einer Platte von A-> B zu kopieren, geht der Context verloren, aber SELinux findet beim Start seine Configdateien und handelt danach.

Jetzt wurden aus Platzgründen auf der SSD diese Dateien beim Kopieren beschädigt, weswegen der Rechner überhaupt gebootet hat, weil damit der Regelsatz gelöscht war. Da aber andere Dateien mit Contexten versehen wurden, was automatisch beim Anlegen einer Datei passiert (z.b. mit cp a b/) , gab es einige Contexte und andere nicht. Besonders das Home-Verzeichnis strotzt nur so vor Contexten.

Jede Fehlermeldung von SELinux wird dem User präsentiert. Dazu poppt auf dem Desktop eine Warnung auf. In dieser Warnung steht auch, was man dem System zu sagen hat, damit es diesen Zugriff zuläßt. Diese Ausnahmen muß es geben, damit Programme über verschiedene Contexte hinweg Daten austauschen können, z.b. Dateien per SSH ins Webverzeichnis spielen, per Samba Dateien kopieren usw.

Heute morgen hat das Chaos dann komplett zugeschlagen. Systemd konnte nicht mehr booten, da erneut SEL-rechte geändert wurden. Das führte zum komischsten Bootbug bisher. „failure to access /dev/initctl“, wo Systemd auf den „initctl“ Socket nicht mehr zugreifen konnte, also auf den eigentlichen Initprozess.

Wie man es behebt

In meinem Fall habe ich von der „alten“ Platte gebootet und systemd neu installiert, damit waren die komischen Bootprobleme behoben, aber die Gnomeshell startete trotzdem nicht. Was im Einzelnen nicht lief, lies sich nicht feststellen, damit man nicht mal mehr im Debugmodus ins System kam.

Abhilfe schaffte das Abschalten von SEL in /etc/selinux/config :

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing – SELinux security policy is enforced.
#     permissive – SELinux prints warnings instead of enforcing.
#     disabled – No SELinux policy is loaded.
SELINUX=permissive
#SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
#     targeted – Targeted processes are protected,
#     minimum – Modification of targeted policy. Only selected processes are protected.
#     mls – Multi Level Security protection.
SELINUXTYPE=targeted

Der Permissive Modus ist eine Art Debugmode, SEL meckert zwar über die Sicherheitsprobleme, verhindert Sie aber nicht. Damit kann das System wieder booten und man kann die SEL Einstellungen und Probleme reparieren.

Ursachenbeseitigung

Wie sich nach nun umfassender Analyse der SEL Konfigurationen gezeigt hat, war der Policyordner defekt. Dateien mit 0 Bytegröße waren die Regel ( weil die Platte zwischenzeitlich voll war ) .

Das Verzeichnis /etc/selinux/targeted stellt den Regelsatz dar, den SEL befolgen soll, so stehts in der config (siehe oben). Diesen Ordner löscht man und ersetzt ihn anschliessend mit einer alten Kopie. In meinem Fall, von der alten Festplatte. Die Verzeichnisstruktur hat sich nicht geändert, also paßt der Regelsatz, da er „Laufwerke“ nicht beachtet, sondern nur „Pfade“ enthält. Der Name des Bootdevices spielt also keine Rolle.

Nun gibt man noch ein :

# restorecond -R -v /*

Das dauert eine Weile, weil alle Files auf der Platte auf den im Regelsatz enthaltenen Wert zurück gesetzt werden. Mit einer SSD ist man in Minuten durch, mit einer SATA dauert es eine halbe Ewigkeit. Vor den vielen Ausgaben nicht erschrecken, es werden fast alle Dateien auf der Platte gerichtet!

Nun stellt man noch SEL in der /etc/selinux/config auf enforcing um :

# SELINUX=permissive
SELINUX=enforcing

Nun kann man rebooten und der Rechner läuft wieder.

Kleiner Tip an die Gemeinde: Kauft gleich eine TB große SSD, wenn Ihr Videos auf der Platte habt. Spart euch das Linken auf die alte Platte, damit spart Ihr euch eine Menge zusätzlichen Ärgers. Das Musik-  und Videos-Verzeichnis hat genauso Contexte wie alles andere und die müssen passen.

So habe ich das gemacht :

# ls -ladZ /home/marius/Videos
lrwxrwxrwx. marius marius unconfined_u:object_r:user_home_t:s0 /home/marius/Videos -> /sata_home/marius/Videos

]$ ls -ladZ /sata_home /sata_home/marius/
drwxr-xr-x. root root system_u:object_r:user_home_dir_t:s0 /sata_home/
drwx——. marius marius unconfined_u:object_r:user_home_dir_t:s0 /sata_home/marius/

In der /etc/fstab dann noch :

/dev/mapper/luks-53246778-9093-123d-235b-4f35522234211 /sata_home ext4 defaults,x-systemd.device-timeout=0 1 2

Eingetragen um die alte Home Partition als /sata_home zu mounten. Da die Passwörter für die Platten gleich sind ( beim Einrichten & Partitionieren der neuen Platte einfach so eintippen ) , wird diese Lukspartition auch automatisch beim Booten entschlüsselt und kann dann gemountet werden.