MacOS X Security

Boah, was für ein Artikel. Geht zusammengefasst um das Sicherheitskonzept von MacOS X, teilweise im direkten Vergleich zu Windows. Unter anderem auch mit der These: Der geringe Marktanteil von Mac OS X ist nicht Schuld an kaum Malware.

Nicht überaus technisch überladen, also sehr verständlich (auf deutsch) erklärt.

Es sind zu viele Informationen auf einmal gewesen, aber beim ersten Durchlesen sind mir keine Fehler aufgefallen. Einzig allein den Passus, dass „Mac OS X“ in großen Teilen offen läge, finde ich unglücklich formuliert. Der Autor meinte sicher, dass viele Komponenten (wie das in dem Kontext genannte Samba) offen sind und von Apple dort auch genutzt werden.

Howto: trac auf Mac OS X 10.6

Für den privaten Gebrauch – und für unterwegs, auf dem mobilen – kann sowohl ein Subversion als auch trac sicherlich eine Offline-Alternative sein.

Tatsächlich suchte ich nun eine Möglichkeit, „mal eben“ eine trac-Instanz aufzusetzen: Auf dem Webserver erschien mir zu komplex und kompliziert, eine neue VM auf dem Macbook etwas ineffizient, oder? 🙂 Also warum nicht direkt unter OS X, bzw. technisch gesehen BSD?

Die initiale Suche nach der Thematik bringt einen schnell zu einer Fink-Lösung – also mal ehrlich, schon etwas aufwendig?

Tatsächlich gibt es auch einfachere Varianten, etwa hier. Aber auch hier wird noch einiges runtergeladen, kompiliert.. ach, Informatiker sind von Grund her faul. Nein, das ist es auch nicht.

# python2.6 ist bereits installiert.
python -version
> Python 2.6.1

Die abgespeckte, und funktionstüchtige Methode lautet daher – kurz und knapp:

sudo easy_install Pygments
sudo easy_install Genshi
sudo easy_install Trac

Das war es, trac ist installiert.

Für diejenigen, die nun auch eine Schnelleinweisung in eine erste Konfiguration brauchen, ein Schnelldurchlauf. Bemerk: Natürlich können auch andere Pfade für die Repositories verwendet werden, wichtig ist nur: Der eigene Benutzer muss später Lese- und Schreibrechte besitzen. Das heißt im Klartext: Entweder nachher „umgranten“ mit chown, oder woanders hinpacken. Auf /usr/local hat in der Regel nur der Superuser Zugriff, d.h. hier muss mit sudo gearbeitet werden.

# ein neues Subversion Repository anlegen
svnadmin create /usr/local/svn
# ein neues trac Repository anlegen - man kann alle Standardwerte nutzen, evtl. Pfad ändern
trac-admin /usr/local/trac initenv

Trac liefert einen kleinen Miniserver mit, der für diesen Zweck erst einmal reicht.

tracd --port 8000 /usr/local/trac/

Voilá.

Selbstverständlich brauchen wir noch einen User, zum Einloggen. Beispiel für den Benutzer user.

htpasswd -c /usr/local/trac/trac.htpasswd admin
> New password:
> New password:
> Re-type new password:
> Adding password for user admin
htpasswd /usr/local/trac/trac.htpasswd knalli
> New password:
> New password:
> Re-type new password:
> Adding password for user knalli

Jetzt den Server mit erweiterteten Parametern starten, also beispielsweise:

tracd --port 8000 --basic-auth=trac,/usr/local/trac/trac.htpasswd,trac /usr/local/trac

Eine Konfiguration über Apache2 ist dauerhaft eventuell zu empfehlen, aber für’s erste reicht es auch so. Ebenfalls empfiehlt die Dokumenation den Einsatz des Parameters –auth (Digest), dazu bitte jene konsultieren.

Starten einer JAR unter Mac OSX – Bad version number?

Wir hatten dieses Thema bereits indirekt durch den ApplicationBundler im Beitrag vorletzter Woche besprochen.. aber hier nochmal zum eigentlichen Problem und dessen Lösung.

Der Fehler verursacht die aktuell ausgewählte Java-Version (und das ist bei den meisten Leuten der Standard Java 1.5.0). Wenn jedoch die Jar mit Java 1.6 kompiliert wurde, kann der 1.5-Loader damit nichts anfangen bzw. schützt aus naheliegenden Gründen vor der Ausführung. Zwar ist auf Mac OS X System der Version 10.5 auch Java 1.6 installiert, dieses ist jedoch kein Standard.

Es gibt dafür nun drei Möglichkeiten:

  1. Der Benutzer startet die JAR nicht mit Doppelklick bzw. dem Kommando „java -jar JarFile.jar“ sondern mit der direkten Angabe im Frameworkverzeichnis.. diese Lösung ist inakzeptabel.
  2. Der Benutzer stellt seine Default-JVM auf 1.6 um.. das machen die Entwickler eh, aber der Benutzer wird auch damit überfordert sein. Auch keine akzeptable Lösung.
  3. Man erstellt eine Mac-Application mit entsprechenden Application-Bootloader und einer Art Manifest, wo eingestellt wird, welche Java-Version verwendet werden muss. Damit findet sich Java 1.6 sogar dann, wenn man als Default 1.4 eingestellt hat. Außerdem hat es den positiven Nebeneffekt, dass die „technische“ Jar vor dem Benutzer durch ein Anwendungsymbol kaschiert wird.

Non-Java exception raised, not handled (Error creating CGSWindow)

Update: It seems that MacWidgets causes this problem. In the applications main frame I added the line

MacUtils.makeWindowLeopardStyle(getRootPane());

If I disable (comment out) this line there will no exceptions. What a..

The structure of components: One Mainframe with BorderLayout (Toolbar, Sidebar and MainContent). The MainContent contains eventually the graph, the corresponding satellite component is in the sidebar.

Original post:

I had already posted about it last week. But now it seems that is was not a reasonable solution.

I have a java swing application which uses standard java swing elements and the jung2 graph framework visualizing graphs. The application is developed under java 1.6 and mac os x 10.5.6.

The actual problem is that since yesterday the AWT-Eventthread crashed, for example like this:

Thu May 7 15:04:28 X.localdomain java[2002] : CGSResolveShmemReference : reference offset (65232) exceeds bounds (32768) on shmem obj 0x257e
Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Non-Java exception raised, not handled! (Original problem: Error (1000) creating CGSWindow)
at apple.awt.CRenderer.doRect(Native Method)
at apple.awt.OSXSurfaceData.doRect(OSXSurfaceData.java:1247)
at apple.awt.CRenderer.fillRect(CRenderer.java:157)
at apple.awt.CRenderer.fillRect(CRenderer.java:145)
at sun.java2d.pipe.ValidatePipe.fillRect(ValidatePipe.java:58)
at sun.java2d.SunGraphics2D.fillRect(SunGraphics2D.java:2501)
at edu.uci.ics.jung.visualization.BasicVisualizationServer.renderGraph(BasicVisualizationServer.java:341)
at edu.uci.ics.jung.visualization.BasicVisualizationServer.paintComponent(BasicVisualizationServer.java:321)
at javax.swing.JComponent.paint(JComponent.java:1027)
at javax.swing.JComponent.paintChildren(JComponent.java:864)
at javax.swing.JComponent.paint(JComponent.java:1036)
at javax.swing.JComponent._paintImmediately(JComponent.java:5096)
at javax.swing.JComponent.paintImmediately(JComponent.java:4880)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:749)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:679)
at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:659)
at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:300)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:210)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:200)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:195)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:187)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

This happens in the event thread, so the application is „still“ useable. Well, of course, the graph painting is a mess.

After googling, I found some solutions:

  1. Execute the file access rights (permissions)-fix via disk utilities & reboot the maschine. Yes, this will fix the problem for some starts, but then.. what a dejavu.
  2. Assure that the paint-process is not outside of the awt-thread.. yes it is. See trace. (Link developer.apple.com)
  3. Exclude the SWT jar.. well, I do not use this and I have not include it. (Link publicobject.com)
  4. Use not the apple ui manager.. well, i replace the manager for the components of jung, i disabled my own selfwritten graph vertex renderer.. no changes. No less exceptions, nothing.

Perhaps this could be an issue by jung, but..

  • why only on this mac – but no error/exception on others systems like windows and linux? Also I have a 2 years older macbookpro.. no problem there.
  • why, or some time, is there no problem after fixing the file access rights (permissions) and rebooting the machine?

Currently, I have no solution.. the exeptions raises while painting the graph (which uses many paint()/Graphs objects ofc) moving/zooming it. I was able to catch some of the strange exceptions overriding the default visualizerviewer (by jung) and put in a small try-catch-wrapper of the corresponding method (here renderGraph). But other exceptions raised within javax.swing.Component and so on…

And.. how strange: the line

Thu May 7 15:04:28 X.localdomain java[2002] <Warning>: CGSResolveShmemReference : reference offset (65232) exceeds bounds (32768) on shmem obj 0x257e

is not an output by the java exception but from the failed native method. The numbers: 32768 (=2^15) and 65232 (2^16 -4). 64bit-problem?

I’m very appreciate if someone has an idea or solution.

Java-Applikation als Mac-Anwendung deployen (Ant)

Wie bereits berichtet, ist es von Vorteil, der Buildprozess mit einem Ant-Script zu automatisieren. Um eine Mac-Application zu erstellen, muss man nur wissen, wie eine solche Application aufgebaut ist.. der Rest ist ein Klacks.

Eine Mac-Application ist ein Verzeichnis mit der Erweiterung .app. Die Struktur einer Application (wir nennen sie im Folgenden Application) sieht wie folgt aus:

  • Application.app
    • Contents
      • Info.plist — Properties-Datei für die Anwendung und Java
      • MacOS — Verzeichnis
        • JavaApplicationStub — Bootloader für Javaprogramme
      • PkgInfo — Datei mit Entwicklerinfo
      • Resources — Verzeichnis mit dem eigentlichen Javaprogramm
        • Java
          • Die Jars und so.

Den Bootloader befindet sich auf einem Mac in dem Ordner /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub.

Prinzipiell kann man sich diese Struktur komplett selber erstellen; es ist aber zu Empfehlen, den initialen Prozess durch das Programm /Developer/Applications/Utilities/Jar Bundler zu machen. Mit Hilfe dieses Programmes lässt sich für eine bereits fertige JAR die Application erstellen.

Anschließend kopiert man das erstellte Resultat – quasi als Vorlage – in ein Verzeichnis für die Builds. In meinem Fall in dem build_data Verzeichnis. Ein Ant-Task erstellt darauf hin im Verzeichnis deploy eine Application. Die Vorlage ist idealerweise auch im SVN und auch später noch veränderbar – beispielsweise durch das Ändern des Applicationicon, -titel oder anderen Einstellungen.

Wichtig 1: Bei Verwendung von FatJar muss man als Package für die Main den Bootloader von FatJar (com.simontuffs.onejar.Boot) verwenden. Dies erkennt das Programm Jar Bundler aber auch automatisch.

Wichtig 2: Beim Kopieren der Dateien kann es passieren, dass die Rechte an der JavaApplicationStub verloren gehen. Diese muss als ausführbar markiert sein. Ein entsprechender Ant-Befehl stellt das sicher.

<target name="makeMac" depends="makeNormal">
<copy todir="deploy/Application.app">
<fileset dir="build_data/Application.app"/>
</copy>
<!-- chmod the application stub file executable -->
<chmod file="deploy/Application.app/Contents/MacOS/JavaApplicationStub" perm="755"/>
<copy file="deploy/Application.jar" tofile="deploy/Application.app/Contents/Resources/Java/Application.jar" />
</target>

Mac OS X Spotlight-Index neu aufbauen

Um den Index neu aufzubauen (beispielsweise aus Gründen der Performance, wenn er kaputt ist, nach einem Plattenwechsel) kann man sich Tools wie Onxy bedienen, die das auf Knopfdruck erledigen. Leider hat das bei mir nicht ganz geklappt, evtl. lag das daran, dass das Volume sich selber auf der Exclusionliste hatte (das hatte ich gemacht, damit ein Fremdsystem nicht den Index kaputt macht, die Idee ist nach hinten losgegangen ;)).

Wie dem auch sei, wenn man so in Google danach sucht, wird einem überall der Befehl sudo mdutil -E / vorgeschlagen. Tatsächlich löscht und deaktiviert dieser Befehl den Index aber nur.. warum schreibt das keiner dahin?

Mac:/ knalli$ sudo mdutil -E /
/:
Indexing and searching disabled.

Etwas schwieriger war es, herauszufinden, wie man den Index wieder aktiviert. Aber, geht natürlich auch, nur anderer Parameter: sudo mdutil -i on /

Mac:/ knalli$ sudo mdutil -i on /
/:
Indexing enabled.

Die alternativen Möglichkeiten haben mir nichts gebracht, es war wirkungslos:

  • Volume in Ausnahmeliste aufnehmen und wieder entfernen (Apple-Lösung)
  • Onxy-Spotlight-Index-Reset (Reset ja, Neuaufbau nein).

Java: Nativer Dateidialog unter MacOS X

Definitiv in der Kategorie: „Was ich schon immer mal wissen wollte..“

Wenn man mit Java Swing ein JFileChooser verwendet, so sieht der unter MacOS X alles andere als schön aus – und nativ ist er sowieso nicht. Was ich nicht wusste: Apple hat das AWT-Pendant FileDialog nativ implementiert (oder nachgebaut?). Gewusst wie – darauf gekommen bin ich auch nur, weil ich einfach mal gesucht habe.

Edit: Wie es aussieht, sieht der FileDialog auch unter Windows besser als sein Swing-Pendant aus. Wie sieht das mit den anderen System aus?

Wie man in MacOS X in der Finder-Sidebar resettet.

Ich hatte das Problem, dass jeder Öffnen und Speichern-Dialog neuerdings mehrere Sekunden brauchte, bis man etwas „machen“ konnte. Zudem war die Liste der „Orte“ (englisch: Places) überfüllt mit Hunderten Einträgen. Meine definierte Liste war etwa 15-20 Items lang, aber diese Liste wurde ein paar Mal wiederholt – strange.

Löscht man die Datei ~/Library/Preferences/com.apple.sidebarlists.plist, loggt sich aus und wieder neu ein, so ist die Sidebar wieder aufgeräumt. Man muss allerdings die Places wieder neu einstellen und ggf. Tweaks wie das Ausblenden der iDisk reaktivieren.