Daten in HKEY_LOCAL_MACHINE ohne Adminrechte schreiben

[jobo]

Zitat:

Daher besteht der Wunsch, das ein Programm beim Start seine Umgebung prüft und einfache Dinge
wie ODBC_Einträge selber anlegt...

Wie schon geschrieben, eine User DSN oder Datei DSN steht unter voller Hoheit des Benutzers.
Wieso willst Du Dich damit quälen, System DSN einzutragen? Doch nicht um Speicherplatz zu sparen oder?

[skyobserver]

Nein, ich will keinen Speicherplatz sparen...

Mir ist klar, daß das ganze Sicherheitstechnisch nicht optimal ist!

Wichtige Stellen in unserem Betrieb arbeiten mit unseren Delphi-Programmen.
Ein längerer Ausfall an einer dieser Stellen kann zum Abstellen der davorliegenden
Produktionsbereiche führen, was zu finanziellen Verlusten in Form von
Produktionsausfall und Strafzahlungen bei verspäteten Lieferungen führt!

Registry-Einstellungen für diese Programme haben in Bereichen, welche der Kontrolle
des Benutzer unterliegen, nichts zu suchen! Betriebsrelevante Einstellungen gehören
imho in Bereiche in denen Benutzer keine Schreibrechte haben!
Und es gibt immer Fuckler die auf Nachtschicht an der Workstation herumspielen
und meinen man könne den PC doch noch optimieren...

Nicht alle Mitarbeiter unserer EDV sind Delphi-Programmierer und gleichermaßen
"Sattelfest" mit den nötigen Einstellungen der vielen Programme.
Ein fehlender Eintrag ist noch leicht als Fehler zu erkennen aber ein verstellter
Parameter kann selbst einen erfahrenen Admin eine lange Suche bescheren...

Ich habe selbst schon erlebt, wie eine Maschine für zwei Tage abgestellt wurde
weil jemand auf einer Workstation mit englischem Bestriebssystem die Ländereinstellungen
von "Englisch" auf "Deutsch" umgestellt hat. Der Bediener hat sich nichts dabei
gedacht: Immerhin hat jeder Benutzer das recht seine Oberfläche anzupassen
und schließlich ist man ja hier in Deutschland...
Dummerweise funktionierte nachher in der Betriebssoftware der Maschine die Konvertierung
von Zahlen und Datumsformaten nicht mehr, weil sich das Zeichen für Dezimal- und
Tausender-Trennung geändert hatten. Der Programmierer (von einer Fremdfirma) hatte
versäumt die Zahl- und Datum-Behandlung Threadsicher zu programmieren damit unabhängig
von den Benutzereinstellungen im Bereich Ländereinstellungen immer das gleiche Ergebnis
herauskommt (Stichwort StrToDate/FormatSettings). Wir konnten den Grund des Fehlers in
der fremden Software nicht ausmachen, und selbst der Programmierer den wir erst am nächsten
Tag erreichen konnten brauchte eine ganze Weile.

Microsoft's Konzept von Sicherheit und Individuellen Einstellungen steht hier in einem
gewissen Konflikt mit der Praxis und der erforderlichen Betriebssicherheit. Hier muß
ich der Betriebssicherheit klar den Vorrang geben.

Mal ehrlich: Wer läßt sich Nachts rausklingeln, sucht nach einem Fehler (was halb
im Schlaf schon mal deutlich länger dauert) und meldet sich dann auf einem System als
Administrator an um Einstellungen vorzunehmen, wenn es auch in weniger als einer Sekunde
(mit vertretbarem Risiko) automatisch geht?

[himitsu]

Threadsicher hat absolut nichts mit unabhängig von den Benutzereinstellungen zu tun.

Wenn Zahlen umkodiert werden sollen, welche festen Definitionen unterliegen, dann müssen auch feste Umkodierungsparameter verwendet werden und nicht irgendwelche systemanhängigen Benutzereinstellungen.

PS: StrToTime und Co. bieten auch ein FormatSettings, wo man die nötigen Werte angeben kann.


Du willst also erreichen, daß Einstellungen im Benutzerkontext von der Anwendung geändert werden können,
aber gleichzeitig dem Benutzer dieses verbieten ... geht nicht, da es ja in seinem Kontext erlaubt ist.
> Die Anwendung mit Admin-Rechten zu starten wird wohl nicht möglich sein, also entweder die Einstellungen liegen im Zugriffsbereich des Benutzers und der der Benutzer kann es ändern oder es liegt nicht in seinem Zuständigkeitsbereich und Er + das Programm kann es nicht ändern.

[p80286]

Hab ich was übersehen?
Was spricht denn dagegen, dem Benutzer die Schreibrechte auf
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC
zu geben?

Da kann man sich die ganze Service / Passwort Hampelei ersparen.

Gruß
K-H

[skyobserver]

@himitsu:

Zitat:

PS: StrToTime und Co. bieten auch ein FormatSettings, wo man die nötigen Werte angeben kann.

Habe ich ja auch geschrieben (genau lesen)! In meinen Programmen mache ich das auch so (jedenfalls seit ich
weiß, daß das problematisch ist - jeder Fehler ist irgendwann der erste)...

Zitat:

Threadsicher hat absolut nichts mit unabhängig von den Benutzereinstellungen zu tun.

Der Begriff "Threadsicher" scheint mir auch unpassend, ich habe ihn direkt der Delphi-Hilfe zum Befehl
StrToDateTime entnommen:

Zitat:

Die erste Form von StrToDateTime ist nicht Thread-sicher, da die landesspezifischen Informationen der globalen Variablen verwendet werden.
Thread-sicheren zweiten Form werden die landesspezifischen Informationen im Parameter FormatSettings übergeben. Bevor Sie diese Form von StrToDateTime aufrufen, müssen Sie die Informationen in den Parameter FormatSettings schreiben. Die landesspezifischen Standardinformationen können mit GetLocaleFormatSettings zugewiesen werden.

@p80286:

Zitat:

Was spricht denn dagegen, dem Benutzer die Schreibrechte auf
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC
zu geben?

Dann hat der Benutzer wieder Eingriffsmöglichkeiten in meine Betriebsrelevanten Einstellungen...

[jobo]

Mir ist eingefallen, dass die Sache mit dem Taskscheduler machbar wäre. Ganz legal und -so hoffe ich- auch mit einer brauchbaren Passwortverschlüsselung.

Man braucht ein lokales oder Domain Konto mit Adminrechten und lässt darunter die Registry Einträge in einem "geplanten Task" ergänzen. Die Dateien können von einem Netzwerkverzeichnis kommen, das ebenfalls nur durch den Admin Account gelesen werden kann (oder zumindest nur durch den geschrieben werden kann)

Ich habs unter XP mit einem lokalen "Admininistrator" und einem lokalen "Benutzer" ausprobiert.
Registry Import mit Create und Silentschalter
Das funktioniert.
Wenn Ihr mit Vista oder höher arbeitet gibts vlt Theater mit UAC oder so.

Das Ganze kann je nach Definition des Tasks sogar vom minder Berechtigten User manuell ausgeführt werden oder per Cmd Script via SCHTASKS.EXE und Desktopverknüpfung als "ODBC Refresh" angeboten werden.

[p80286]

Zitat von jobo:

Die Dateien können von einem Netzwerkverzeichnis kommen, das ebenfalls nur durch den Admin Account gelesen werden kann (oder zumindest nur durch den geschrieben werden kann)

Mir hat bisher noch keiner der Benutzer eine ODBC-Einstellung "zerschossen". Und wenn dann doch einmal ein "Fachmann" am Werke war, dann wie JoBo vorgeschlagen hat, eine .reg Datei auf einem schreibgeschützten Laufwerk und gut war's.

Gruß
K-H