Skip to content

Genauer hingeschaut: Kritik an Automatix

Anfang des Monats hat Matthew Garrett für das Ubuntu Technical Board, welches unter anderem den Standard für Ubuntu-Pakete und Installationsprozesse festlegt, das Programm Automatix untersucht. In seinem Bericht hat er Automatix kein gutes Zeugnis bescheinigt, was dazu führte, dass die Automatix-Anhänger gegen Matthew Garret und Ubuntu wetterten und sogar Ubuntu Forums einer Verschwörung bezichtigten, weil diese aufgrund der hohen Anfrage "automatix" als Suchwort temporär ausgeschlossen haben. Aber auch einige Mitglieder der Ubuntu-Gemeinschaft bekleckern sich nicht mit Ruhm, wenn sie nun "automatix sucks" schreien.

Insgesamt gibt es aktuell zwei Fronten: Die einen sind der Meinung, dass Automatix am besten verboten werden sollte, weil sie ja schon immer wussten, dass das Programm schädlich (und sicher auch für Hungersnöte und Umweltkatastrophen verantwortlich) ist. Die andere Seite steckt den Sand in den Kopf und meint lapidar: "Bei mir funktioniert's aber!". Beide Parteien haben leider nicht verstanden, was Matthew Garrett mit seiner Analyse, die er keineswegs verfasst hat, um mal eben über Automatix herziehen zu können, aussagen will: Automatix macht einige Dinge nicht auf die korrekte Art und Weise, die ein System beschädigen oder zumindest durcheinanderbringen kann. Die Betonung liegt aber auf "kann", denn nicht bei jedem muss dies der Fall sein. Noch präziser: Bei den wenigsten Anwendern tritt dieser Fall überhaupt ein. Das ändert aber nichts daran, dass das Programm Fehler enthält. Sicherheitslücken in einem Browser werden zum Beispiel auch nicht erst dann geflickt, wenn genügend Leute davon betroffen waren.

Aus diesem Grund will ich den Blogeintrag von Matthew Garrett übersetzen, da vor allem deutschsprachige Anwender Probleme haben könnten, die genaue Aussage des Textes zu verstehen. Es hat sich zum Beispiel gezeigt, dass viele nicht den Unterschied verstehen, zwischen dem Paket Automatix, dem Programm Automatix und den Programmen, die Automatix (ggf. durch neue Softwarequellen) installiert. Das Paket hat zwar auch einige Fehler, auf die weiter unten eingegangen wird, die aber keineswegs sicherheitsproblematisch sind. Und auch die durch Automatix installierte Software ist so vertrauenswürdig, wie diese eben sein kann, wenn man sie sich manuell herunterladen oder eine Paketquelle von Hand hinzufügen würde. Es geht in dem Bericht also nur um die Auswirkungen des Programmes Automatix und dessen Verhalten.

Neben der eigentlichen Übersetzung gibt es von mir extra ausgewiesene Erläuterungen in kursiver Schrift, da im Originalartikel davon ausgegangen wird, dass einige Sachverhalte bekannt sind, was bei einem Standardanwender sicherlich nicht der Fall ist. Ich sage aber gleich dazu, dass ich selbst kein Profi auf diesem Gebiet bin und mich bei den Erläuterungen auch irren kann oder diese nicht verstehe (siehe unten). Ich bitte das an dieser Stelle zu berücksichtigen und zu entschuldigen.

Beschreibung

Automatix ist eine Mischung aus Systemkonfigurations- und Paketinstallationsprogramm, das dabei hilft Software wie Grafiktreiber, Codecs oder Programme, die nicht in den Ubuntu-Quellen liegen, zu installieren. Das Programm wird als deb-Paket angeboten, welches eine in Python geschriebene Oberfläche bereitstellt, die dann die zugehörigen Befehle auf der Shell aufruft. Über XML-Dateien, die Modulbeschreibungen und Funktionsnamen enthalten, wird das Backend gesteuert. Ein Installationsmodul überprüft, ob ein anderer Paketmanager läuft und installiert dann ein Deb-Paket oder ein Tarball, falls nicht. Ein Deinstallationsmodul entfernt die Software wieder und löscht gegebenenfalls manuell installierte/kopierte Dateien.

Nachfolgend findet man eine Liste alle Fehler der aktuellen Version von Automatix. Es wird aber keinen Wert auf Vollständigkeit gelegt, da Matthew Garrett das Programm nur ein paar Stunden getestet hat.

Automatix als Paket

Das Paket hat eine niedrige Qualität, da es nicht dem Debian- oder Ubuntu-Standard für Pakete entspricht:

  • Es wird fälschlicherweise der Sektion "base" (deutsch: "Basissystem") zugeordnet.
    In dieser Sektion sollten sich nur extrem wichtige Dateien befinden, ohne die das System nicht auskommen kann.
  • Es hängt von essentiellen Paketen ab.
    Dies sind Pakete in Ubuntu, wie zum Beispiel das Paket bash, welche man zwar deinstallieren kann, nur funktioniert danach das System nicht mehr. Solche Pakete nennt man "essentiell" und man muss ein eigenes Paket nicht von diesen abhängig machen, da man ohne es nicht einmal zur Installation käme.
  • Die Kurzbeschreibung ist länger als 80 Zeichen und die ausführliche Beschreibung fehlt gänzlich.
  • Die E-Mail-Adresse im Maintainer-Feld fehlt.
    Man weiß also nicht direkt, wer der Ansprechtpartner ist, wenn es Probleme mit dem Paket gibt.
  • Die Copyright-Dateien liegen nicht an den dafür vorgesehenen Stellen.
  • Im Control-Archiv findet man eine Datei TODO.
    Alle Dateien im gepackten Archiv control.tar.gz sind Steuerungsdateien, die sagen, wie das Paket installiert werden soll, wovon es abhängt, etc. Hier findet man normalerweise nur eine Datei control. Eine TODO-Datei enthält meist nur Aufgaben, die sich der Ersteller merken will und noch erledigen muss. Sie gehört nicht in das Control-Archiv.
  • Es gibt keine Man-Pages.
    Dies ist essentiell für ein ordentliches Paket, selbst wenn in der Man-Page nur steht: "Bitte schauen sie im Ordner ... für ausführliche Informationen".
  • Es werden Dateien in /usr/etc abgelegt.
    /usr/etc ist kein Standardsystemordner und existiert normalerweise nicht. Automatix legt hier beispielsweise die oben erwähnten XML-Dateien ab.
  • Viele Dateien sind als ausführbar markiert, obwohl es zum Beispiel nur normale Textdateien sind.
  • Das Changelog findet man in /usr/etc/automatix2/ax_data, wo es nicht hingehört.

Diese Fehler sind aber nur kosmetischer Natur, die sich leicht beheben lassen und auch kein Sicherheitsproblem darstellen.

Automatix als Programm

  • Im Debugmodus erstellt Automatix Dateien als Root im Homeverzeichnis. Dies ist kein Sicherheitsproblem, aber verwirrend, wenn man selbst im eigenen Ordner nicht mehr Herr über alle Dateien ist.
  • In /usr/share werden plattformspezifische Daten angelegt, was bei einer gemeinsamen Nutzung des Verzeichnisses bei verschiedenen Architekturen zu Probleme führen kann. Da Automatix aber nur als x86 und amd64-Programm erhältlich ist, sollte das kein so großes Problem sein.
  • Über das Skript #!/bin/bash #created by arnieboy foo=`gksudo -u root -k -m "enter your password for gedit root access" /bin/echo "Do you have root access?"` sudo gedit $NAUTILUS_SCRIPT_SELECTED_URIS soll sichergestellt werden, dass der ausführende Benutzer sudo-Rechte hat. Das funktioniert aber nicht, wenn man timestamp_timeout auf 0 setzt. Dieses Verhalten zieht sich durch das ganze Programm durch, ebenso wie die Annahme, dass "sudo" nicht nach dem Passwort fragt.
    Normalerweise merkt sich das System das sudo-Passwort nach der Eingabe für 15 Minuten. Mit timestamp_timeout kann man diese Zeit festlegen, so dass das Passwort gar nicht mehr gemerkt wird.
  • Der Rechtschreibfehler in catagory_data.xml ist eigentlich fast zu vernachlässigen.
  • Der Hinweis Please NOTE that downloading and installing w32codecs, libdvdcss2 and other non-free codecs without paying a fee to the concerned authorities constitutes a CRIME in the United States of America ist sehr zweifelhaft, da das Problem der beiden genannten Pakete sicher keine Gebührenfrage und auch nicht auf die USA beschränkt ist.
  • Automatix überprüft anhand einer Liste, ob gegebenenfalls andere Paketverwaltungsprogramme laufen. Es unterbindet danach aber keinen Start derer. Dies könnte zu einer Race Condition führen.
  • Das Skript if ps -U root -u root u | grep "dpkg" | grep -v grep;   then     killall -9 dpkg kann das System in einem inkonsistenten und nicht mehr startbaren Zustand hinterlassen und wird dazu ohne Warnung ausgeführt. Aus diesem Grund befindet sich immer noch eine Sperrdatei (Lock-File) auf dem System. Dieses Verhalten ist so nicht zu akzeptieren.
    Das Problem bei dem Signal '-9' (SIGKILL) ist, dass der Prozess sofort unterbrochen wird; er hat keine Chance mehr irgendwelche Operationen zu beenden. In dem Fall kann auch eine Sperrdatei, welche die Paketverwaltung dpkg setzt, wenn es startet, nicht mehr gelöscht werden. So eine Sperrdatei sorgt dafür, dass immer nur eine Paketverwaltung zu einem Zeitpunkt auf die Paketdatenbank Zugriff erhält.
  • Die Funktion function reloadnautilus {   killall -9 nautilus } wird zwar nirgends gebraucht, würde aber ohne Warnung möglicherweise zu Datenverlust führen, da Nautilus einfach geschlossen wird.
  • Die meiste Installationsroutinen haben ohne ersichtlichen Grund einen Warteschleife (sleep) implementiert. Danach rufen sie eine andere Funktion (dpkg_check) auf, welche wieder wartet. Es ist unklar, was damit bezweckt wird.
  • An apt-get wird während der Ausführung die Option --assume-yes übergeben, was ohne Eingreifmöglichkeit Pakete entfernt, wenn es das System für notwendig erachtet. Das ist vor allem problematisch, wenn man ein Programm deinstalliert, welches von anderen Programmen abhängt, die aber nicht über Automatix mitinstalliert wurden. Diese werden dann ebenfalls ohne Rückfrage entfernt.
  • Es gibt kein internes Paketverwaltungssystem. Das bedeutet, es kann, wie im Punkt vorher schon beschrieben, nicht überprüft werden, welche Software durch Automatix installiert wurde und welche es wieder entfernen darf. Die Installation des Swiftfox-Plugins zum Beispiel zieht die Installation einiger anderer Plugins nach, die bei einer Deinstallation von Swiftfox aber nicht wieder mit entfernt werden. Man müßte also danach die Pakete per Hand aufräumen.
  • Automatix hat kein Dateiüberwachungssystem und deinstalliert ganze Verzeichnisse, auch wenn darin Dateien liegen, die nicht von Automatix angelegt wurden. Zusätzlich wird nicht überprüft, ob ein Programm bereits vorher manuell in /opt vom Benutzer installiert wurde. Es beansprucht auf diese Art und Weise das /opt-Verzeichnis für sich selbst.
  • Automatix entfernt ohne Warnung (sichere) Pakete aus den Ubuntu-Quellen, um dann (unsichere) Programme aus einem Tar-Archiv zu installieren.
  • Wenn man Strg+Alt+Entf einstellt, um den GNOME-Systemmonitor zu starten, werden alle existierenden Benutzerkonfigurationen für run_command_9 überschrieben.
    Viele Benutzer möchten wie unter Windows über Strg+Alt+Entf den Systemonitor starten. run_command_9 im Konfigurationsmonitor ist für diese Tastenkombination zuständig.
  • Wenn man Streamtuner installiert, wird ein Verzeichnis /opt/ripped erstellt, welches für alle Nutzer schreibbar ist ohne ein Sticky-Bit zu setzen. Dadurch können sich Benutzer gegenseitig behindern.
  • Das MPlayer-Plugin kopiert Totem-Plugins in einen Sicherungsordner, aber verhindert nicht, dass bei einer Paketaktualisierung von Totem die ersetzen Dateien überschrieben werden.
  • Bei der Installation von Java wird nur der java-Link angepasst, aber nicht die Links zu den anderen Java-Programmen in /etc/update-alternatives/.
  • Die Installation des AOL-Messengers überschreibt die tls-Bibliothek aus dem Paket tcltls. Dadurch ist die MD5-Summe nicht mehr gültig und das Paket invalide.
  • sudo ln -s /usr/lib/libesd.so.0 /usr/lib/libesd.so.1 ist keine gute Idee.
    Ich sehe dies so, dass absolute Links in einem System nie sinnvoll sind. Sobald z.B. das System anderweitig eingebunden wird (sei es durch eine Live-CD oder ein chroot), funktionieren diese Links nicht mehr bzw. erledigen nicht das, was sie sollen, da sie nicht auf das eigentliche System zeigen.
  • ln -s /tmp/.esd-1000 /tmp/.esd könnte wahrscheinlich nur für den ersten Benutzer des System funktionieren.
    Der erste Benutzer im System hat immer die Benutzer-ID 1000.
  • sudo sed -i "s/^vboxusers\(.*\):$/vboxusers\1:$AXUSER/" /etc/group nimmt an, dass das System kein User Directory Service benutzt.
    Hier weiß ich nicht, was genau die Nachteile davon sein könnten.
  • Truecrypt wird mit SUID-Bit als Root installiert. Wenn man auf die Sicherheitsprobleme der Vergangenheit bei Truecrypt zurückblickt, ist das keine gute Idee.
    Das SUID-Bit erlaubt es einem Benutzer ein Programm nicht mit den eigenen Rechten, sondern denen des Besitzers (in dem Fall Root) auszuführen. Das Bit sollte wirklich nur in wichtigen Fällen gesetzt werden.
  • Automatix hängt Dateisysteme aus, ohne danach zu überprüfen, ob der Vorgang komplett abgeschlossen wurde.
  • Aus der /etc/fstab, in der die Datenträger des System gelistet sind, werden Zeilen entfernt und durch die absolute Geräteadressen ersetzt.
    Seit Ubuntu 6.10 "Edgy Eft" werden hierfür aber die UUIDs benutzt, da diese nur von der Partion selbst abhängen und nicht von dem Ort, an dem sie eingebunden sind. Diese Änderung kann also dazu führen, dass vor allem Systeme mit Wechselplatten nicht mehr korrekt starten, sollte sich die Reihenfolge der eingehängten Geräte ändern.
  • Der Adobe Reader wird in der Version 7.0.9 installiert, obwohl die neue Acrobat-Lizenz eine solche Verteilung nicht mehr erlaubt.

Fazit

Automatix befriedigt einige wichtige Bedürfnisse, vor allem für neue Benutzer. Es ist aber noch mehr Arbeit notwendig, damit das Paket auch den Anforderungen von Ubuntu stand hält. In der aktuellen Form ist das Programm gefährlich für das System, wobei die Bandbreite von kleinen Beschädigungen von Benutzerkonfigurationen über das Entfernen von Paketen ohne Rückfrage oder Warnung bis hin zu der kleinen, aber vorhandenen Wahrscheinlichkeit, dass das System nicht mehr startet, reicht.

Der aktuelle Aufbau von Automatix verhindert eine einfache Behebung einige der Fehler. Das Programm soll sich wie ein anspruchsvoller Paketmanager verhalten, ohne die dafür notwendige Abhängigkeitsverwaltung und Paketüberwachung selbst zu beherrschen.

Eine Alternative wäre es, dass das Automatix-Team nur deb-Pakete als Installer für die Software anbietet, die es aktuell installiert. Diese können dann durch einen existierenden Paketmanager installiert werden. Die Lösung würde einige der obigen Probleme nicht mehr besitzen und dennoch die gleiche Funktionalität bieten.

Aktuell ist Automatix aber nicht zu betreuen und die Möglichkeit, Bugs zu kennzeichnen, bei denen Automatix mit auf dem Rechner installiert ist, würde sicher dabei helfen, festzustellen, ob ein Problem auf ein unterstützes Paket aus den Ubuntu-Quellen oder auf Drittanbieter-Software basiert.

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Matthias am :

Ich denke mittlerweile ist die Ubuntu-Community so groß, dass die durchschnittliche Ignoranz der Menschen deutlicher zu Tage tritt. Besonders wenn auf ernst gemeinte und sachliche Kritik einfach mit primitiven Beleidigungen reagiert wird. Ist schon interessant, dass einigen Benutzern so die Distanz fehlt, dass sie Programmfehler ihres Lieblingswerkzeuges als persönlichen Angriff werten. Vielen Dank für die schöne Übersetzung und den objektiven Beitrag.

lunar am :

* sudo ln -s /usr/lib/libesd.so.0 /usr/lib/libesd.so.1
ist keine gute Idee.
Neben der Tatsache, dass der Link absolut ist, ist vor allem der Link selbst ein Problem! Die Nummer am Ende des Namens geben afaik die Versionsnummer der Bibliothek an. Programme können so direkt gegen eine bestimmte Version der Bibliothek linken, so es denn erforderlich ist. Durch den obigen Link wird einer Anwendung eine ältere esd Version als neu untergeschoben, was unter Umständen ein undefiniertes Verhalten der Anwendung hervorrufen kann.


* sudo sed -i "s/^vboxusers\(.*\):$/vboxusers\1:$AXUSER/" /etc/group
nimmt an, dass das System kein User Directory Service benutzt.
Hier weiß ich nicht, was genau die Nachteile davon sein könnten.

Bei einem Directory Service werden Gruppen nicht mehr über /etc/group verwalten, sondern in der Regel auf einem zentralen Server. Firmen verwenden diese Infrastruktur, um Rechte zentral zu verwalten. Wenn ein solcher Dienst verwendet wird, funktioniert die obige Ersetzung nicht, sie zeigt keine Auswirkungen, da die Rechte an anderer Stelle bestimmt werden.

Dee am :

Danke für die weiteren Ausführungen. Das hilft den Lesern hoffentlich und ich bin auch wieder ein Stück schlauer! :) Dee

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Formular-Optionen