Erste Erfahrungen als unpriviligierter Neuling

[r3d3]

Ich arbeite aus Sicherheitsgründen unter Windows XP grundsätzlich als unprivilegierter Benutzer.
Nun habe ich soeben BayWotch heruntergeladen und installiert (über Ausführen als...) Das war auch erfolgreich. Jedoch scheiterte der erste Programmstart schon an folgender Fehlermeldung:



Ein Klick auf "Abbrechen" führt nur zur wiederholten Anzeige der Fehlermeldung. Entweder man beendet den Prozess über den Task Manager oder man klickt auf "OK", was dann nicht wie angekündigt zum Fortfahren sondern zum Beenden führt.

OK, dachte ich, ein witziger Programmierer. Fehlt nur noch die Schaltfläche "Vielleicht".

Das Auftreten des Fehlers erschien mir sehr logisch, hatte ich das Programm doch als Benutzer gestartet, der selbstverständlich nicht in das Programm-Verzeichnis schreiben darf. Also gab ich der Gruppe "Benutzer" Änderungsrechte auf die Datei. Ein neuer Versuch führte zu dieser Fehlermeldung:



Diesmal verhalten sich die Schaltflächen "OK" und "Abbrechen" wie erwartet. Die Datei runtime.txt exisitert logischerweise in keinem der beiden Fälle.

Nun frage ich mich:

1. Warum verhält sich ein Windows-Programm, was immerhin schon in Version 3 vorliegt, nicht windowskonform? Daten gehören nun mal nicht in das Programmverzeichnis, sondern unter %USERPROFILE%\Anwendungsdaten. Einstellungen werden nicht in eine INI-Datei im Programmverzeichnis geschrieben, sondern in die Registry unter HKCU\Software. Und das ist bereits seit 11 Jahren so, seit es Windows 95 gibt. Was würde passieren, wenn zwei Personen den selben Computer benutzen würden?
2. Warum entsteht die zweite Fehlermeldung, wenn man nicht als Administrator das Programm gestartet hat? Und welche Folgen hat die Weiterarbeit durch Klick auf "OK"?

Ich kann verstehen, dass eine kostenlose Light-Version Einschränkungen gegenüber einer kostenpflichtigen Vollversion hat. Aber diese Einschränkungen sollten nicht die Sicherheit beeinträchtigen. Der Autor schreibt selbst auf seiner Webseite zu den Einschränkungen:

jedoch werden diese niemanden davon abhalten, alle Funktionen und Leistungsmerkmale von BayWotch in aller Ruhe auszuprobieren. Bei der Konzeption der verschiedenen Lizenzmodelle wurde streng darauf geachtet, daß die Light Version nur Einschränkungen enthält, die den Benutzer zwar zum Kauf anregen, nicht aber an einem intensiven Test und sogar der täglichen Nutzung hindern.

Wenn ein Programm die Sicherheit einschränkt, überlege ich schon, ob ich es so dringend brauche, dass ich mit dem erhöhten Risiko leben will.

Ein Versuch, die Pfade in der Datei baywotch3.ini manuell anzupassen, schlug fehl. Allerdings ist das in der sehr guten ausführlichen Dokumentaton auch beschrieben. Beim Überfliegen der Doku ist mir allerdings aufgefallen, dass es nicht nur vier Einschränkungen gibt, wie auf der Webseite
Features und Preise beschrieben, sondern 13.

So das reicht als erster Eindruck. Nun werde ich das Programm ausprobieren.

[denkmann]

Hallo r3d3,
erst einmal herzlich Willkommen im Forum!

Warum verhält sich ein Windows-Programm, was immerhin schon in Version 3 vorliegt, nicht windowskonform? Daten gehören nun mal nicht in das Programmverzeichnis, sondern unter %USERPROFILE%\Anwendungsdaten. Einstellungen werden nicht in eine INI-Datei im Programmverzeichnis geschrieben, sondern in die Registry unter HKCU\Software. Und das ist bereits seit 11 Jahren so, seit es Windows 95 gibt. Was würde passieren, wenn zwei Personen den selben Computer benutzen würden?

Die großen Vorteile der INI Datei sind die Flexibilität bzgl. Sicherung, Umzug, Support und Deinstallation der Software. Daher nutze ich auch heute noch diesen Weg.

Das Thema wurde hier im Forum schon heftig diskutiert. Ich gebe Dir Recht, daß dies noch verbessert werden kann:
http://www.baywotch.de/phpbb/viewtopic.php?t=1268
http://www.baywotch.de/phpbb/viewtopic.php?t=1159

Warum entsteht die zweite Fehlermeldung, wenn man nicht als Administrator das Programm gestartet hat? Und welche Folgen hat die Weiterarbeit durch Klick auf "OK"?

Solche Fehlermeldungen sind Ausnahmezustände, für die es keine garantierten Abläufe gibt. Andere Programme stürzen ab, lassen Windows Schutzverletzungen aufpoppen oder verschwinden einfach sang- und klanglos vom Screen. BayWotch hingegen fängt alle Laufzeitfehler ab und dokumentiert diese, um die Weiterentwicklung zu optimieren. Programmierer sind hier getrennter Meinung, ob es besser ist, Laufzeitfehler zu unterdrücken (was sich dann in Form von fehlerhaften Programmabläufen wiederspiegeln kann) oder ab man bei jedem kleinen Fehler Alarm schlägt, was den User natürlich beunruhigt und verwundert, wenn dann das Programm dann nach "OK" nicht mehr weiterläuft.

Es bleibt jedoch ein sog. "unerwarteter Fehler" (natürlich: hätte ich ihn erwartet, würde er ja nicht auftreten ), der im Regelfall das Programm stört oder abbricht. Die Funktionen [OK] und [Abbrechen] sind dabei "gut gemeinte" Interaktionsmöglichkeiten, die je nach Fehler funktionieren, oder aber auch nicht (wenn Qualm aus dem Motorraum kommt, läßt sich auch nicht mit Gewißheit sagen, ob im Armaturenbrett noch die entsprechende Kontrollleuchte blinkt, oder schon verglüht ist )

Die von Dir beschriebenen Fehlermeldungen sind mit Gewißheit auf die fehlenden Berechtigungen zurückzuführen, wobei der 2. Fehler im Datenbanktreiber selber (DAO.Workspace) aufgetreten ist, also in einem externen Treiber.

Beim Überfliegen der Doku ist mir allerdings aufgefallen, dass es nicht nur vier Einschränkungen gibt, wie auf der Webseite
Features und Preise beschrieben, sondern 13.

Da kann ich Dir nicht ganz folgen. Meinst Du jetzt, es gibt 13 Einschränkungen der Light Version gegenüber der Enterprise Version? Das könnte durchaus hinkommen.

Die von mir genannten 4 Einschränkungen sind die Einschränkungen, welche die Light Version gegenüber der Standard Lizenz aufweist (wobei noch kein Light Benutzer von mir bei einer E-Mail-Anfrage ignoriert wurde... es sind demnach eigentlich nur 3 ).

[r3d3]

erst einmal herzlich Willkommen im Forum!

Danke!

Die großen Vorteile der INI Datei sind die Flexibilität bzgl. Sicherung, Umzug, Support und Deinstallation der Software.

OK, dagegen ist aus meiner Sicht grundlegend nichts einzuwenden. Aber dann sollte man das Prinzip der Registry (HKLM, HKU) nachimplementieren. Also eine INI-Datei im Programmverzeichnis, in der nur der Admin scheiben kann und eine INI-Datei je Benutzer in %USERPROFILE%\Anwendungsdaten. Die benutzersprezifische muss immer zuerst eingelesen werden, damit Einstellungen des Admins immer wirken.

Das Thema wurde hier im Forum schon heftig diskutiert.

Habe beide Threads gelesen. War sehr anstrengend! Jedoch zeigt es mir, dass ich nicht der Einzige bin, der sich für die Anwendung der MS-Prinzipien ausspricht. Auch in einem UNIX wird niemand auf die Idee kommen, Benutzern Schreibrechte unterhalb von /usr/bin zu erteilen.

Was mir bei der Diskussion jedoch aufgefallen ist: Jeder spricht sich für erhöhte Datensicherung aus, wenn keine Schreibrechte auf das Programmverzeichnis erteilt werden. Keiner bedenkt aber, dass ein Schadprogramm, was unter einem unprivilegierten Konto läuft, natürlich die gesamte Datenbank verändern oder lösche kann. Daher denke ich, dass hier weiter gedacht werden muss. Auch mir war das beim Schreiben meines ersten Postings nicht aufgefallen. Meine Überlegungen gehen dahin, dass die Datenbank schon im Programmverzeichnis bleiben muss und Benutzer keine Schreibrechte darauf haben dürfen. Damit trotzdem sinnvoll gearbeitet werden kann, muss man mit DB-Benutzern arbeiten. So könnte sich der Prozess baywotch.exe unter einem DB-Benutzerkonto bei der DB anmelden und hätte dann die Rechte dieses Users. Die Vorgehensweise wäre vergleichbar mit der Arbeit im Internet. Wenn ich als Anwender bei xxx etwas bestelle, schreibe ich auch nicht direkt in die Datenbank von xxx, sondern der vom Webserver gestartete Prozess tut das. Auf diese Weise wäre nicht nur das Programm BayWotch und dessen Dateien sicherer sondern auch die Datenbank.

Was die Behandlung von Fehlermeldungen betrifft, so schlage ich hier einen Mittelweg vor. Da ich selbst programmiere, weiß ich, dass die korrekte Fehlerbehandlung mindestens genauso viel Code verschlingt, wie die eigentlichen Programmroutinen. Fehlermeldungen müssen für den Anwender aussagefähig sein. Für ihn muss ersichtlich sein, was er nun tun muss/kann. Bei MS liest man oft Meldungen der Art: "... Fragen Sie Ihren Administrator...". Das regt zwar zur Heiterkeit an, lässt sich aber nicht anders lösen. Ein Benutzer kann nun mal nicht Programme und OS adminstrieren und soll es auch nicht. Also bietet es sich an, auch hier einen ähnlichen Weg zu beschreiten. Die Idee mit der Datei runtime.txt ist schon prima, nur sollte sie dort gespeichert werden, wo es auch möglich ist. Wie wärs mit %TEMP%? Bei Fehlermeldungen, wie Zugriffsverletzungen, kann man einfach schreiben, dass versucht wurde, lesend/schreibend auf die Datei ... zuzugreifen und der Administrator um Erteilung der notwendigen Berechtigungen gebeten werden soll. Bei Fehlermeldungen, deren Ursache nicht klar ist, bittet man den Anwender, die Datei runtime.txt an den Programmierer zu schicken, falls es er eine kostenpflichtige Version von BayWotch einsetzt. Wer die kostenlose Version benutzt, soll Hilfe im Forum suchen.

Und daher frage ich bezüglich des zweiten von mir geposteten Fehlers (DAO.Workspace) auch noch einmal nach. Welche Berechtigungen fehlen wo?

PS: Ich habe versucht, den Beitrag ohne persönliche Angriffe zu formulieren. Sollte sich doch jemand getroffen fühlen, bitte ich um eine PM, damit solche Diskussionen nicht im Forum ausgetragen werden müssen.

[denkmann]

Hallo r3d3,

Deine Vorschläge sind dankend aufgenommen.

Da Du selber programmierst, weiß Du, daß man nicht selten Kompromisse eingehen muß. Kompromisse aufgrund von Zeitmangel, Kompatibilität, Programmiersprache, persönlichen Meinungen, vertraglichen Vorgaben etc. Es ist leider nicht immer möglich, alles zu implementieren, was sinnvoll und/oder reizvoll ist.

Monatlich erreichen mich zig Mails mit Wünschen und Verbesserungsvorschlägen zu BayWotch. Es ist kein leichter Job, zu entscheiden, welche der Features realisiert werden. Im Vordergrund steht dabei natürlich der Erfolg des Programms und daraus resultierend die Meinung der Kunden.

Selbstverständlich werde ich mich zu gegebener Zeit mit diesem Thema näher auseinandersetzen. Momentan sind die Prioritäten aber noch anders verlagert.

Und daher frage ich bezüglich des zweiten von mir geposteten Fehlers (DAO.Workspace) auch noch einmal nach. Welche Berechtigungen fehlen wo?

In dem besagten Modul wird versucht, mittels einer DAO-OpenDatabase Anweisung die BayWotch Datenbank mit den Optionen lesend und shared zu öffnen. Dies scheitert vermutlich aufgrund fehlender Berechtigungen. Genauer kann ich das Problem aus der Ferne leider nicht analysieren.

PS: Ich habe versucht, den Beitrag ohne persönliche Angriffe zu formulieren.

Das ist Dir m.E. 100% gelungen!

[r3d3]

@Elmar

Microsoft stellt nun ein Tool für Programmierer bereit, mit denen sie den eingeschränkten Zugriff ihres Programms testen können. Ich habe es mir noch nicht angesehen, aber vielleicht ist es ja eine Hilfe für dich:

http://www.heise.de/newsticker/meldung/73581