Softpicks.Net Deutsch

[F.M.Keller]

"Ruediger Lahl" <ruediger.lahl [at] gmx.de> schrieb im Newsbeitrag
news:es58ft.2d4.1 [at] privat.lahls.de...
> Hallo zusammen
>
> Mein Vista hat bei der Installation gleich neben dem 'Programme'-Ordner
> ein 'ProgamData' angelegt. Seltsamerweise wollen sich aber alle
> Programme nach 'Program Files' installieren. Ebenso gibt es neben
> 'Dokumente und Einstellungen' ein: 'Documents and Settings'. Was habe
> ich bei der Vista-Installation flasch gemacht?
> --
> bis denne

Nix! Das ist völlig richtig so und soll auch so sein! Am besten, du liest
gleich hier:
http://blogs.technet.com/dmelanchthon/archive/2006/11/24/kein-zugriff-auf-verzeichnisse-unter-windows-vista.aspx
denn sonst lässt die nächste Frage "warum habe ich 'da-und-da' keinen
Zugriff nicht lange auf sich warten!
Gruss
FMK

.

[Tom]

"Benjamin Zielke" <Darkspy [at] hotmail.de> schrieb im Newsbeitrag
news:C7A48925-564F-47F7-A203-F7A0F6A51205 [at] microsoft.com...
>
> "Ruediger Lahl" <ruediger.lahl [at] gmx.de> schrieb im Newsbeitrag
> news:es58ft.2d4.1 [at] privat.lahls.de...
>> Hallo zusammen
>>
>> Mein Vista hat bei der Installation gleich neben dem 'Programme'-Ordner
>> ein 'ProgamData' angelegt. Seltsamerweise wollen sich aber alle
>> Programme nach 'Program Files' installieren. Ebenso gibt es neben
>> 'Dokumente und Einstellungen' ein: 'Documents and Settings'. Was habe
>> ich bei der Vista-Installation flasch gemacht?
>> --
>> bis denne
>
>
> Gar nichts !
> Das ist vollkommen normal.

Mhm, auf meinem System gibt es z.B. keinen Program Files sowie Documents and
Settings Ordner.

cu
Tom

.

[Ruediger Lahl]

*F.M.Keller* schrieb:

>> Mein Vista hat bei der Installation gleich neben dem 'Programme'-Ordner
>> ein 'ProgramData' angelegt.
>
> Nix! Das ist völlig richtig so und soll auch so sein!

Der Zweck erschließt sich mir nicht.
--
bis denne
.

[Daniel Melanchthon [MS]]

Hallo Wolfgang Bauer,

Wolfgang Bauer <bauerwol [at] gmail.com> schrieb:
> Und die sollte man aktiviert lassen um eben diese Verwirrung zu
> umgehen. Übrigens sollte man eigen installierte Programm nicht nach
> Program Files installieren weil es Probleme mit den Schreibrechten
> gibt. Besser in einen neuen Ordner "Öffentlich\Programme" oder noch
> besser in ein anderes logisches Laufwerk.

das Gegenteil ist der Fall: Programme sollten in einen Ordner
installiert werden, indem der normale Benutzer keine Schreibrechte
hat. Das ist bei C:\Programme der Fall.

Viele Grüße!
--
..:Daniel Melanchthon:.
http://blogs.technet.com/dmelanchthon
This posting is provided "AS IS" with no warranties, and confers no
rights.

Koinzidenz begründet keine Korrelation und ist kein Beweis für
Kausalität!

.

[Wolfgang Bauer]

Daniel Melanchthon [MS] wrote:
> Hallo Wolfgang Bauer,

> Wolfgang Bauer <bauerwol [at] gmail.com> schrieb:
>> Besser in einen neuen Ordner "Öffentlich\Programme" oder noch besser
>> in ein anderes logisches Laufwerk.

> das Gegenteil ist der Fall: Programme sollten in einen Ordner
> installiert werden, indem der normale Benutzer keine Schreibrechte
> hat. Das ist bei C:\Programme der Fall.

Und wenn man dann Programme hat die ihre Daten im Programmordner
rückspeichern wie Dialog geht das nicht. Auch der Hamster macht da
Probleme. Außerdem ist es auch bei einer nötig werdenden Neuinstallation
sicherer wenn die Programmdateien auf einem anderen logischen Laufwerk
liegen.

Wolfgang
.

[Dirk Herkner]

Ruediger Lahl <ruediger.lahl [at] gmx.de> meinte:

>
>Finde ich nicht. Es sind zwei Ordner für die selbe Aufgabe.

Da würde ich an deiner Stelle noch mal genau hingucken. Ich sehe da nur
einen Ordner und eine Verknüpfung.
--
Gruß Dirk
.

[Wolfgang Bauer]

Daniel Melanchthon [MS] wrote:
> Hallo Wolfgang,
> "Wolfgang Bauer" <bauerwol [at] gmail.com> schrieb:

>> Und wenn man dann Programme hat die ihre Daten im Programmordner
>> rückspeichern wie Dialog geht das nicht. Auch der Hamster macht da
>> Probleme.

> Schon seit Jahren dürfen Benutzer nicht in Programmeordner schreiben.

Es gibt aber Programme die das machen (wollen). Programme die ansonsten
so gut sind, daß man sie auch gerne unter Vista benutzen möchte.
40tude-Dialog ist z.B. solch ein Programm. Und der Entwickler hat sich
durchaus dabei etwas gedacht. (siehe unten)

>> Außerdem ist es auch bei einer nötig werdenden Neuinstallation
>> sicherer wenn die Programmdateien auf einem anderen logischen Laufwerk
>> liegen.

> Das klingt für mich nicht plausibel. Was ist der Vorteil? Du mußt doch
> beim Neuinstallieren auch die Anwendungen reinstallieren, da alle
> Einträge von denen z.B. in der Registry fehlen.

Ja, es sind viele Programme die sich in die Registry eintragen, die
müssen dann auch neu installiert werden. Es sind aber bei Weitem nicht
alle. Hier möchte ich auch wieder Dialog anführen, unter Windows der
beste Newsreader. Da findet man bei der *Installation* zwar auch einen
Eintrag in der Registry aber nur um Dialog als Standardnewsreader zu
kennzeichnen. Wenn man das komplette Dialog Programmverzeichnis kopiert,
von einem Laufwerk auf ein anderes oder von einem PC zum anderen, gibt
es keinen Reg-Eintrag und der ist ach nicht nötig. Dialog, und es gibt
auch andere Programme nach dieser Entwicklerphilosophie, ist dadurch
mobil, auf einem USB Stick etwa, unabhängig von der Registry und der
Windowsumgebung.

Das der Vistabenutzer trotz Administrativen Rechten keine vollen Rechte
hat habe ich schon sehr bald erfahren. Ein eben unter meinem eigenen
Account ungewollt nach C:\Program Files\ installiertes Programm ließ
sich nicht deinstallieren oder löschen.

Wolfgang
.

[Daniel Melanchthon [MS]]

Hallo Wolfgang,

"Wolfgang Bauer" <bauerwol [at] gmail.com> schrieb:
>> Schon seit Jahren dürfen Benutzer nicht in Programmeordner schreiben.
>
> Es gibt aber Programme die das machen (wollen). Programme die ansonsten
> so gut sind, daß man sie auch gerne unter Vista benutzen möchte.
> 40tude-Dialog ist z.B. solch ein Programm. Und der Entwickler hat sich
> durchaus dabei etwas gedacht. (siehe unten)

wie schon geschrieben, ein Workaround ist die Rechtevergabe auf den
Programmeordner. Ob der Entwickler sich dabei etwas gedacht hat, dass
sein Programm den Benutzer dazu zwingt, lokal administrative Rechte
haben zu müssen, sei mal dahingestellt.

> Das der Vistabenutzer trotz Administrativen Rechten keine vollen Rechte
> hat habe ich schon sehr bald erfahren. Ein eben unter meinem eigenen
> Account ungewollt nach C:\Program Files\ installiertes Programm ließ
> sich nicht deinstallieren oder löschen.

Das ist ein anderes Problem.

Viele Grüße!
--
..:Daniel Melanchthon:.
http://blogs.technet.com/dmelanchthon
This posting is provided "AS IS" with no warranties, and confers no rights.

Koinzidenz begründet keine Korrelation und ist kein Beweis für Kausalität!

.

[Peter Götz]

Hallo Daniel,

> wie schon geschrieben, ein Workaround ist die
> Rechtevergabe auf den Programmeordner. Ob
> der Entwickler sich dabei etwas gedacht hat,
> dass sein Programm den Benutzer dazu zwingt,
> lokal administrative Rechte haben zu müssen,
> sei mal dahingestellt.

Ich denke, die Frage sollte man anders stellen:
Was haben sich die Windows-Entwickler dabei gedacht, zwar eine Möglichkeit
zu schaffen, dass normale Benutzer benutzerbezogene Daten/Einstellungen in
der Registry (HKCR) oder in den benutzerbezogenen SpecialFolders (Eigene
Dateien usw,) speichern können, aber keine Möglichkeit zu lassen,
benutzerunabhängige (für alle Benutzer zugängliche Daten/Einstellungen) in
der Registry oder in den SpecialFolders (AllUsers) zu speichern?

Als Entwickler steht man immer wieder vor dem Problem, dem Anwender die
Möglichkeit geben zu müssen, sowohl benutzerbezogene als auch
benutzerunabhängige Informationen irgendwo speichern zu können. Das
Rechtekonzept von Windows (nicht nur Vista) sieht das nicht vor und zwingt
einen als Entwickler immer wieder zu allen möglichen oder umöglichen
Klimmzügen.

Gruß aus St.Georgen
Peter Götz (MVP)
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)


.

[Daniel Melanchthon [MS]]

Hallo Peter,

"Peter Götz" <gssg_nospam [at] t-online.de> schrieb im Newsbeitrag
news:O0cj9rYXHHA.4308 [at] TK2MSFTNGP05.phx.gbl...
> Meine Programme laufen im Regelfall aber nicht unter Admin-Kennung und haben
> somit keine Schreibrechte in HKLM. Gleiches gilt für AllUsers in den
> SpecialFolders. Auch hier kann mein Programm, welches unter einer normalen
> Benutzerkennung läuft keine Einträge schreiben.

das verstehe ich nicht. Ein Programm bekommt keine Rechte, sondern der
Benutzer, der das Programm ausführt.

>> Datzu gibt es noch die Policyfunktion,
>> mit der Du granular benutzer- und/oder maschinenspezifische Optionen
>> konfigurierbar oder zentral vorgebbar machen kannst.
>
> Das ist alles keine Lösung für ganz alltägliche Abläufe.

Das kann ich dir so pauschal nicht glauben.

> Mehrere Benutzer arbeiten mit ProgrammX. Sie machen im Programm
> benutzerspezifische Einstellungen wie Schriftarten, Schriftgrössen, Farben,
> Fenstergrössen, Fensterpositionen usw.
> Müller mag es bunt, Maier hats lieber Grau in Grau usw., jeder halt seine
> ganz persönlichen Ansichten.
> Praktikabler Speicherort für diese Einstellungen:
> Registry HKCR oder "Eigene Dateien"

OK. Die Einstellungen, die die Benutzer ändern können, sind in HKCU gut
aufgehoben. Soweit so gut. Zusätzlich solltest Du dort nach Policies
differenzieren, so dass ein Admin Einstellungen, die eigentlich pro
Benutzer wählbar sind, trotzdem verpflichtend vorgeben kann. Diese
sollten dann in Deiner Anwendung auch ausgegraut sein, damit der Anwender
sieht, dass er die Einstellung nicht verändern kann.

> Im selben Programm müssen aber auch programmbezogene Einstellungen wie z.B.
> Datenbankpfade, bestimmte Dateipfade usw. geändert und gespeichert werden
> können, die dann für alle anderen Benutzer auch sichtbar und wirksam werden.
> Der hierfür vorgesehene Speicherort Registry HKLM oder SpecialFolders
> AllUsers ist aber versperrt, da das Programm ja nicht mit Admin-Rechten
> läuft und somit per Default keine Schreibrechte in HKLM bzw. AllUsers hat.

Genau diese Daten hat aber der Benutzer nicht zu verändern. Damit er es
nicht kann, sind die maschinenbezogenen Einstellungen in HKLM etc. gerade
nicht schreibbar für den Anwender. Das ist genau so gewollt und auch sinnvoll.

Wenn der Benutzer die Berechtigung hätte, diese Werte ändern zu können, wie
willst Du dann sicherstellen, dass einzelne Benutzer diese Werte nicht
verstellen und dann das Programm nicht mehr für alle Benutzer richtig läuft?

> Ich will erreichen, dass "mein" Programm benutzerunabhängige
> Einstellungen/Informationen nicht nur lesen sondern auch schreiben kann.

Aber Dein Programm wird doch in einem bestimmten Kontext aufgerufen. Lieschen
Müller als normale Benutzerin macht darin ihre tägliche Arbeit und stellt sich
vielleicht ihr bevorzugtes Farbprofil ein. Max Admin dagegen startet das
Programm als lokaler Administrator und konfiguriert zum Beispiel den
Datenbankpfad. Das soll Lieschen Müller auch nicht verstellen können. Da er
mit einem lokalen Adminaccount das Programm zur Konfiguration gestartet hat,
kann er auch die Änderung machen und in HKLM speichern. Oder er greift zu
Gruppenrichtlinien und gibt die ganze Konfiguration zentral vor - auch hier
kann er HKCU und HKLM Daten verändern.

Wo ist das Problem jetzt genau?

> Der Workaround sieht so aus, dass ich im zur Anwendung gehörenden
> Setup-Programm, welches mit Admin-Rechten läuft, z.B. in der Registry unter
> HKLM ein Unterverzeichnis anlege und dieses für normale
> Benutzer/Benutzergruppen zugänglich mache. In dieses Verzeichnis kann dann
> später vom eigentlich Programm aus ohne Admin-Rechte auch geschrieben werden
> um bestimmte Einstellungen/Informationen für alle Benutzer zugänglich zu
> machen.

Damit können aber *alle* Benutzer diese Werte auch ändern, löschen, etc. Damit
sind diese Daten in keinster Weise geschützt. Das einzige, was Du erreichst,
ist, dass Du die Trennung Benutzer vs. Administrator aufhebst. Deine Benutzer
sind dann zwar keine lokalen Admins im Bezug auf Windows - im Bezug auf
Deine Anwendung sind aber alle Benutzer Administratoren. Das nenne ich einen
Pyrrhussieg.

Viele Grüße!
--
..:Daniel Melanchthon:.
http://blogs.technet.com/dmelanchthon
This posting is provided "AS IS" with no warranties, and confers no rights.

Koinzidenz begründet keine Korrelation und ist kein Beweis für Kausalität!

.

[Wolfgang Bauer]

Hans-Peter Grözinger wrote:

> Dann gehören _diese_ Daten aber nicht in die Registry/INI-Datei
> sondern in die Datenbank.

Eben, das geht aber nicht wenn die Programme in "C:\Program Files\"
installiert sind.

Wolfgang
.

[Peter Götz]

Hallo Wolfgang,

> Wobei wir wieder ziemlch am Anfang sind. Es gibt eben
> Programme die das nicht zulassen, die ihre Daten
> zwangsweise im Programmordner speichern.

Das können Sie bei einem normal konfigurierten System spätestens seit Win2k
nicht mehr, da auch hier normale Benutzer keine Schreibrechte haben, sofern
dies nicht explizit unter Adminrechten verändert worden ist. Ich denke auch,
dass der Pfad der Anwendung (Application.Path) auch nicht wirklich der
geeignete Ort für solche Daten wäre. Ein versehentliches Löschen oder
Verändern der *.exe könnte doch unangenehme Folgen haben.

Gruß aus St.Georgen
Peter Götz [MVP]
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)



.

[Wolfgang Bauer]

Peter Götz wrote:
> Hallo Wolfgang,

>> Unter WinXP hatte der erste eingerichtete User
>> Adminrechte

> Nicht unter WinXP sondern unter WinXP home.

Das war und ist auch so bei WinXP professionell.

>> was mit der nötigen Vorsicht und hinter einem
>> Rooter als alleiniger User an einem Einzelplatz
>> PC auch nicht gefährlich war.

> Nun wird man bei industriellen Anwendungen wohl eher sehr selten WinXP home
> antreffen und völlig vom Rest der Welt abgeschlossene Einzelrechner ohne
> Verbindung zu einem LAN sind dort auch eher eine Seltenheit. Es ist bei den
> genannten industriellen Anwendungsbereichen auch eher unüblich, mit lokalen
> Benutzerkonten zu arbeiten, die Regel sind von einem Domänencontroller
> verwaltete Benutzerkonten.

Du hast den Threadbeginn nicht gelesen. Da ging es /noch/ nicht um diese
speziellen Anwendungen.

>> Deswegen und weil es Programme gibt die ihre Daten
>> im eigenen Programmordner ablegen,

> das können sie aber nur, wenn sie unter einer Benutzerkennung laufen, die in
> diesem Verzeichnis Schreibrechte hat.

Wenn ich als Benutzer einen Ordner "Programme" anlege und dort
Anwendersoftware installiere dann /habe/ ich dort als dieser Benutzer
Schreibrechte.

>> installiere /ich/ Programm nach D:\Programme\.

> Und was machst Du, wenn es nur ein Laufwerk C: gibt?

Dann lege ich mir, z.B. mit Acronis DiskDirectorSuite, auf C:\ ein
weiteres logisches Laufwerk an. (wenn der Platz da ist)

> Oder was, wenn das Laufwerk D: ein Netzlaufwerk ist?

Dann ist es eben E:

Wolfgang
.

[Peter Götz]

Hallo Daniel,

> Meine Erfahrung zeigt, dass Anwendungsentwickler sich
> meistens gar nicht alle Einsatzszenarien und Kundenwünsche
> vorstellen können.

Das kann ich mir eigentlich nur schwer vorstellen.
Zumindest bei meinen Kunden ist es so, dass vor der eigentlichen Erstellung
eines Programms viele lange und ausführliche Gespräche stehen, in denen
gemeinsam ein sehr detailliertes Pflichtenheft erstellt wird. Darin sind
Einsatzszenarien und Kundenwünsche natürlich exakt beschrieben.

> Dass ist jetzt ganz allgemein gemeint und nicht auf
> ich speziell gemünzt. Vielleicht snd Deine Programme
>und Deine Kunden anders -

Das sind in der Regel Industrieunternehmen und Behörden.

> lerdings kannst DU dann nicht von Deiner
> Umgebung auf andere schliessen.

Das will ich eigentlich auch gar nicht.

> > Es gibt für diese Anwendungen keine Einstellungen,
> > die der normale Anwender nicht verändern darf.
> > Einstellungen unterscheiden sich lediglich darin, dass
> > sie einmal benutzerabhängig (Schriften, Farben) usw.
> > sind und einmal eben nicht benutzerabhängig
> > (Datenbankpfade, Dateipfade).
>
> Das ist der Unterschied in der Denkweise:

Nein, nicht in der Denkweise, sondern bei den realen Anforderungen der zu
lösenden Aufgabe.

> Für mich als Administrator sind nicht benutzerabhängige
> Daten auch nicht durch Benutzer zu ändern.
> Ich gehe dabei vom Worstcase aus - böswillige Benutzer

Ein unberechtigter, böswilliger oder auch unfähiger Benutzer, wird von
vorneherein durch eine programminterne Benutzerverwaltung und Rechtevergabe
ausgeschlossen.

> (oder Malware in ihrem Kontext) könnten
> damit die Anwendung für alle Anwedner lahmlegen.

Auch das kann man weitgehend ausschliessen.
Ein LAN, welches vorrangig die Kommunikation zwischen Maschinen und
Messautomaten ermöglicht, wird man nicht unbedingt mit einer permanenten
Internetverbindung ausstatten und auch sonst wird man peinlich genau darauf
achten, dass dort keine unerwünschten Programme eingebracht werden.

> >> Genau diese Daten hat aber der Benutzer
> >> nicht zu verändern.
> >
> > Genau diese Daten muss er eben verändern können.
> > Ein Admin wäre dazu weder zeitlich noch vom Wissen
> > her in der Lage. Der Admin weiss nicht, wann
> > bestimmte Messautomaten bestimmte Eingangsdaten
> > woher beziehen sollen und weiss auch nicht, wann
> > diese ihre Daten in einer von vielen möglichen
> > DB-Dateien ablegen sollen.
>
> Das muss ja nicht zwingend ein Netzwerk-Administrator sein.
> Das kann auch ein Benutzer sein, der "Administrator"
> für diese Aufgabe ist.

Ja, genau solche Benutzer sind das.

> So wie es aussieht, wäre eine Rechteprüfung in der
> Anwendung dafür sinnvoller, als die Boardmittel
> zu "mißbrauchen".

Eine solche ist natürlich vorhanden und die lässt es z.B. auch nicht zu,
dass der Mitarbeiter am Ende der Arbeitskette, beim Verpacken der
gefertigten Bauteile einen Datenbankpfad oder bestimmte Dateipfade für die
Anwendung ändert. Dieser Mitarbeiter bekommt natürlich von der
programminternen Rechteverwaltung weitaus eingeschränktere Rechte zugewiesen
als z.B. ein verantwortlicher Schichtleiter.

Die zu solchen Änderungen berechtigten Benutzer, arbeiten aber eben auch
nicht mit Admin-Rechten und deshalb sind für sie per Default eben Pfade wie
HKLM und/oder AllUsers erst mal nicht beschreibbar.

>
> >> Damit er es nicht kann,
> >
> > Das ist ja das hüpfende Komma, er soll und
> > muss ja können.
>
> Genau das unterscheidet Deine Anforderung.
> Aus Deiner Besonderheit kannst
> Du aber keine Allgemeingültigkeit proklamieren.

Na ja, "proklamieren" wäre mir dann auch etwas zu hoch gegriffen. Aber eine
so exotische Besonderheit sind solche Anwendungen nun wirklich nicht. Gerade
in der industriellen Fertigung gibt es solche mit schöner Regelmässigkeit.

> > Und genau das ist der Denkfehler, den es genau
> > so in .net / VS.net miti den Settings gibt.
> > Auch hier gibt es per Default keine Möglichkeit,
> > dass normale Benutzer ohne Adminrechte "nicht
> > benutzerbezogene" Settings speichern.
>
> Weil es keinen Sinn macht. Was ist, wenn diese
> "nicht benutzerbezogenen" Daten
> gelöscht oder beliebig verändert werden?

Erst mal ist das eben nur den Personen möglich, die von der programminternen
Benutzerverwaltung dazu berechtigt sind. Weitere Hürden sind eine Rückfrage
beim Benutzer und eine Plausibilitätsprüfung, die Fehlbedienungen zwar nicht
gänzlich verhindern kann, aber doch sehr unwahrscheinlich macht.
Das letzte Wort hat natürlich in jedem Fall der "berechtigte" Anwender und
er trägt auch die Verantwortung für sein Tun.

> Dann wird die Anwendung nicht wie gewünscht
> funktionieren. Du gehst von sich vernünftig verhaltenden
> Benutzern aus.

Ja, das muss ich und das kann ich auch.
Kein Industrieunternehmen der Welt wird an irgendeiner Produktionsstätte zur
Einstellung und Überwachung von Produktionsabläufen Personal einsetzen, das
nicht hinreichend ausgebildet ist und verantwortliches Handeln erwarten
lässt.

> Das ist nicht überall der Fall.

Natürlich ist das nicht überall der Fall.
Genauso falsch wäre aber die Behauptung, dass es überall der Fall wäre.

> Die Trennung Administrator vs. Benutzer
> gibt es ja nur deswegen.

Die gibt es auch in diesem konkreten Fall.
Genau deshalb sollen ja auch die zu solchen Änderungen berechtigten
Mitarbeiter nicht mit Adminrechten arbeiten. Das Betriebssystem, das LAN mit
den Servern und alles was mit deren Verwaltung zu tun hat, ist Sache des
Admins. Eingriffe in arbeitstechnische Abläufe einer industriellen
Produktion sind es aber in keinem Fall.

..... schnipp....

> > Da sitzen nicht irgendwelche ahnungslosen Leute vor
> > den Rechnern, sondern Ingenieure und bestens
> > ausgebildete Techniker, die sehr genau wissen, wann
> > sie z.B. DB-Pfade für das Speichern von Messdaten
> > bzw. Dateipfade aus denen sich Maschinen und
> > Messautomaten bestimmte Steuerdaten holen
> > entsprechend den akt. Arbeitsabläufen zu ändern haben.
>
> Genau das ist in der Regel nicht der Fall (meine Erfahrung).

Doch, genau so ist es in jedem Industriebetrieb, in dem Produktionsstrassen
und autom. Messeinrichtungen eingestellt und überwacht werden müssen.

> Bei Dir sehe ich
> eher eine Spezialumgebung.

Das ist der ganz normale Alltag in einer industriellen Fertigung.

> >> Da er mit einem lokalen Adminaccount das Programm
> >> zur Konfiguration gestartet hat, kann er auch die
> >> Änderung machen und in HKLM speichern.
> >
> > Kann er eben aus zeitlichen und aus
> > verfahrenstechnischen Gründen nicht.
>
> Das Argument finde ich ein wenig dünn.

Nein, das ist einfach die Realität.
Woher soll denn ein Admin wissen, wann und wie eine Fertigungsstrasse welche
Bauteile produziert, wann dabei bestimmte Parameter verändert werden müssen,
wann und welche Eingriffe notwendig sind, weil irgendein Messautomat meldet,
dass Fertigungstoleranzen überschritten werden, usw. usw.? In einer solchen
Umgebung sind immer wieder Eingriffe notwendig, die eben nur von
entsprechend ausgebildetem Personal vorgenommen werden können und dürfen.
Und solche Eingriffe sind nicht nur alle paar Tage oder Wochen, sondern
ständig, mehrmals täglich, oft sogar im Abstand von wenigen Minuten
erforderlich.

.... schnipp...

> >> Wo ist das Problem jetzt genau?
> >
> > Das Problem ist, dass die Windowsentwickler offenbar
> > der Meinung waren/sind, dass auf einem Rechner nur
> > simple Büroanwendungen laufen, die von mehr oder
> > weniger in Sachen Datenverarbeitung ungeschulten
> > Leuten bedient werden und diese somit grundsätzlich
> > als potentielle Systemgefährder zu betrachten
> > sind.
>
> Nicht grundsätzlich - aber die Möglichkeit ist durchaus
> gegeben. Also muss es dafür Lösungsmöglichkeiten geben.
> Was Du Dir wünschst, klingt nach dem
> Rechte- und Sicherheitskonzept von Windows 95 ;-)

Nein, das wünsche ich mir ganz sicher nicht.
Man kann es eigentlich ganz einfach beschreiben.
Gäbe es z.B. in der Registry neben HKLM, wo es durchaus sehr restriktiv zuge
hen kann und soll, einfach einen weiteren für alle Benutzer sichtbaren
Bereich, der aber auch von diesen beschreibbar ist, hättet man ein einfaches
Mittel, genau das von mir beschriebene Szenario ohne grossen Aufwand zu
beherrschen.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)


.

[Daniel Melanchthon [MS]]

Hallo Peter,

"Peter Götz" <gssg_nospam [at] t-online.de> schrieb:
> Zumindest bei meinen Kunden ist es so, dass vor der eigentlichen Erstellung
> eines Programms viele lange und ausführliche Gespräche stehen, in denen
> gemeinsam ein sehr detailliertes Pflichtenheft erstellt wird. Darin sind
> Einsatzszenarien und Kundenwünsche natürlich exakt beschrieben.

Du sprichst von Individualsoftware - Windows ist aber eine Massensoftware
für hunderte von Millionen Anwendern. Da kann man es nicht allen recht
machen.

> Ein unberechtigter, böswilliger oder auch unfähiger Benutzer, wird von
> vorneherein durch eine programminterne Benutzerverwaltung und Rechtevergabe
> ausgeschlossen.

Das ist schön für Dich und Deine Umgebungen - das gilt aber nicht für
andere. Und Registrykeys kann man auch direkt verändern, ohne Dein
Programm. Rate mal, warum es eine Funktion in Windows gibt, die
Regedit sperrt. Auch diese Lösung hindert einen findigen Anwender nicht,
die Registry z.B. mit einem Skript direkt zu ändern. Und solche
Anwender habe ich zur genüge schon kennengelernt.

> Auch das kann man weitgehend ausschliessen.
> Ein LAN, welches vorrangig die Kommunikation zwischen Maschinen und
> Messautomaten ermöglicht, wird man nicht unbedingt mit einer permanenten
> Internetverbindung ausstatten und auch sonst wird man peinlich genau darauf
> achten, dass dort keine unerwünschten Programme eingebracht werden.

Du beschreibst es ja selbst: Du hast eine spezielle Umgebung und spezielle
Anforderungen. Was ich davon ableite, ist, dass Du nicht erwarten kannst,
das jetzt in Windows alles so gemacht wird, dass Deine speziellen Wünsche
erfüllt werden.

>> Weil es keinen Sinn macht. Was ist, wenn diese
>> "nicht benutzerbezogenen" Daten
>> gelöscht oder beliebig verändert werden?
>
> Erst mal ist das eben nur den Personen möglich, die von der programminternen
> Benutzerverwaltung dazu berechtigt sind.

Du gehst davon aus, dass sie nur Dein Programm dafür verwenden. Das
muss aber nicht der Fall sein - überall, wo Benutzer schreiben oder
löschen können, ist damit auch zu rechnen (Worst Case). Du bittest
Deine Anwender ja auch nicht in Deiner Anwendung, nur dort Dinge
umzustellen, wo sie es sollen und andere, die sie ändern könnten,
doch bitte nicht umzustellen, weil sie es nicht sollen.

> Ja, das muss ich und das kann ich auch.
> Kein Industrieunternehmen der Welt wird an irgendeiner Produktionsstätte zur
> Einstellung und Überwachung von Produktionsabläufen Personal einsetzen, das
> nicht hinreichend ausgebildet ist und verantwortliches Handeln erwarten
> lässt.

Das bestreite ich (vehement). Da habe ich genug Gegenbeispiele gesehen.

> Die gibt es auch in diesem konkreten Fall.
> Genau deshalb sollen ja auch die zu solchen Änderungen berechtigten
> Mitarbeiter nicht mit Adminrechten arbeiten. Das Betriebssystem, das LAN mit
> den Servern und alles was mit deren Verwaltung zu tun hat, ist Sache des
> Admins. Eingriffe in arbeitstechnische Abläufe einer industriellen
> Produktion sind es aber in keinem Fall.

Na dann pack doch auch die Dinge, die diese Ändern sollen, nicht in den
administrativen Bereich des Betriebssystems, sondern in die Anwendung.

Viele Grüße!
--
..:Daniel Melanchthon:.
http://blogs.technet.com/dmelanchthon
This posting is provided "AS IS" with no warranties, and confers no rights.

Koinzidenz begründet keine Korrelation und ist kein Beweis für Kausalität!

.