Updates

• 20. Februar 2018

Ich stand und stehe immer noch der Implementierung des Modulsystems in Java9 ablehnend gegenüber. Neulich war es draußen so, dass ich lieber drin blieb und ich erinnerte mich an eine Test-Suite, die ich bei der Umstellung auf Java8 dazu nutzte, Imkompatibilitäten meiner Anwendungen festzustellen und auszumerzen.

Zu den Test-Themen zählten unter anderem:

• Custom ClassLoader
• Java3D
• JAAS
• Java Webstart (als Server und Client)

Ich reaktivierte also diese kleinen Tests und ließ mich überraschen. Tatsächlich wurde ich auch überrascht: der JAAS-Test schlug fehl. Ich brauchte einige Zeit, dahinterzukommen warum er fehlschlug.

Dazu vielleicht zunächst ein wenig Hintergrund: Das JAAS-Szenario sah so aus, dass ich darüber die Authentifizierung realisierte. Dadurch wird ein Principal aufgebaut, der dann vom SecurityManager benutzt wird um zu prüfen, ob der Code, der gerade ausgeführt wird, auch über die entsprechende Permission verfügt.

Ich benutzte zur Erstellung des Prinzipals den com.sun.security.auth.module.UnixLoginModule. Unter Java8 funktionierte der Test problemlos, unter Java9 wurden keinerlei Permissions vergeben.

Nach langwieriger Suche stellte sich die Situation für mich so dar, dass Oracle selbst das neue Modulsystem nicht restlos durchschaut, denn im Zuge der Arbeit des SecurityManager wird an den Principals die Methode hashCode aufgerufen - die wiederum die Methode toString aufruft, um den Hash aus dem resultierenden String zu errechnen.

Da die Methode toString jedoch die Stringrepräsentation aus ResourceBundles (Stichwort I18n) zusammensetzt, fliegt unter Java9 eine ResourceNotFoundException, weil das benötigte ResourceBundle nicht im Klassenpfad gefunden werden kann.

Das wirklich witzige daran ist, dass man diesen Fehler umgehen kann, wenn man direkt nach dem Login alle Principals des Subject holt und an jedem vorsorglich einmal die toString-Methode aufruft. Zu diesem Zeitpunkt weiß Java noch, wo das ResourceBundle im ClassPath liegt und das sorgt dafür, dass die Ressourcen dann auch gefunden werden, wenn der SecurityManager sie benötigt.

Die Dateien zum Nachvollziehen sind angehängt: Unter Java8 funktioniert die Beispielanwendung mit oder ohne Kommandozeilen-Parameter, unter Java9 funktioniert sie nur mit Kommandozeilenparameter - das schaltet nämlich den Workaround an...

Die Anwendung muss mit den drei System-Properties

• java.security.auth.login.config
• java.security.manager
• java.security.policy

gestartet werden, damit JAAS entsprechend konfiguriert wird und der SecurityManager über die Rechte des Principals informiert ist.

Ich habe nicht versucht, ob derselbe Mechanismus mit denselben fatalen Folgen unter Windows zum Tragen kommt.

Ein entsprechender Bug wurde gemeldet und ist zur Zeit intern unter Review.

JAAS-Konfiguration

Security-Policy

Beispielanwendung

Aktualisierung vom 20. Februar 2018

Artikel, die hierher verlinken

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )