• [gelöscht]

  • Bearbeitet
Hallo,

bei mir ist die aktuelle Thunderbird-Version installiert. Beim Start erhalte ich ein Warnfenster mit dem Hinweis, dass die Sicherheitskomponente der Anwendung nicht geladen werden kann. Es folgen weitere Hinweise auf möglicherweise eingeschränkte Zugriffsrechte auf Verzeichnisse oder eine volle Fesatplatte. Nach dem Klick auf den OK-Button der Meldung startet Thunderbird und es folgt eine weitere Warnung, dass die Adressbuch-Datei nicht geladen werden kann. Logischerweise fehlen die Adressbücher dann auch in der Anwendung. Wahrscheinlich liegt es daran, dass ich die Thunderbird-Profile auf einer Datenpartition ausgelagert habe, dies also nicht im Standardpfad liegen.

Frank
Das hatte ich hier auch mal...weiß nur nicht mehr genau, wo.
Ich teste mal neu.
Habe gerade Thunderbird 2.0.0.17 installiert und das Problem tritt nicht auf :'(

Ich habe das aber definitiv auch schon mal gesehen, bekomme es aber nicht mehr hin.

...ich denke mal, dass das nicht an SuRun liegt.
1.) Falls TB nicht mit SuRun gestartet wird - und warum sollte man das tun[1]? - hat es mit SuRun nichts zu tun.

2.) Könnte es sein, daß das TB-Profil vom Admin-Konto oder unter Verwendung eines per SuRun laufendes Explorers / Dateimanagers verschoben worden ist? Kopiere das Profil mit eingeschränkten Rechten an einen neuen Ort (nicht: verschieben) und verwende es dort. (Falls das Profil durch die bisherigen Aktionen allerdings beschädigt sein sollte, wäre die Wiederherstellung aus einer hoffentlich vorhandenen Sicherung erforderlich.) Ansonsten erstelle ein neues Profil.

[1] Einziger vernünfiger Grund wäre ein Online-Update des Programms. Ich rate davon allerdings dringend ab, nachdem ich die Erfahrung gemacht habe, daß das Update dabei möglicherweise stecken bleibt und anschließend auch aus dem Admin-Konto nicht mehr durchgeführt werden kann. Aber selbst wenn - das Profil bleibet davon unberührt.

P.S. Ich arbeite seit dem ersten Erscheinen von TB 1.5 mit verschobenen Profilen, die auch schon mehrere Umzüge hinter sich gebracht haben. Ein Profil-Schaden ist nie aufgetreten. Wichtig ist, daß der eingeschränklte Benutzer auf alle Dateien uneingeschränkte Rechte zum Schreiben und Löschen hat.
  • [gelöscht]

  • Bearbeitet
Thunderbird starte ich nur mit SuRun um den oben geschilderten Fehler zu umgehen. Wenn ich Thunderbird über Surun mit Admin-Rechten starte tritt der Fehler nämlich nicht auf.

In meinem ersten posting hatte ich mich bezüglich der Intallation mißverständlich ausgedrückt. Korrekt sieht es wie folgt aus: Thunderbird ist nicht im Standard-Installationspfad installiert, sondern auf einer Daten-Partition. Dort befindet sich auch ein weiteres Verzeichnis mit den mail-accounts.

Vor der Installation von Surun lief der verwendete XP-Account mit Admin-Rechten, jetzt natürlich als SuRunner.
Ich hatte die Vermutung, dass es jetzt Probleme mit den Zugriffsrechten auf die Thunderbird-Verzeichnisse gibt und über die Dateifreigabe sowohl dem Benutzer als auch der Gruppe SuRunner Vollzugriff auf die entsprechenden Verzeichnisse gegeben. Leider hat dies garnichts geändert.

Kopieren der Verzeichnisse an andere Stelle und neu einbinden kann ich natürlich mal probieren. Wenn es sich jedoch jedoch um ein Problem mit den Zugriffsrechten handelt (und ich wüßte im Moment keine andere Erklärung), muß sich das auch anders lösen lassen.

Frank
Frank wrote: Thunderbird starte ich nur mit SuRun um den oben geschilderten Fehler zu umgehen. Wenn ich Thunderbird über Surun mit Admin-Rechten starte tritt der Fehler nämlich nicht auf.
Welchen? Die Warnmeldung wegen der nicht geladenen Sicherheitskomponente?

TB ist sicherheitstechnisch ein gutmütiges Programm. Für den Programmordner werden Rechte zum Lesen und Ausführen benötigt, keine Schreibrechte. Wenn diese gegeben sind und für das Profil die von mir bereits genannten vollständigen Rechte, gibt es diese Warnung nicht. TB wäre längst zerrissen (und nicht kurz vor der Veröffentlichung der Version 3 angekommen), wenn es im eingeschränkten Konto nicht fehlerfrei ausführbar wäre. Ist es das nicht, so hat es eine spezifische Ursache, SuRun ist hier als Problemlöser fehl am Platz. Ach ja, mit der jetzigen Information hört sich das nun auch gar nicht mehr danach an, als ob du durch SuRun ein Problem festgestellt hättest.

Das hier erregt allerdings meinen nächsten Verdacht:
Frank wrote: Thunderbird ist nicht im Standard-Installationspfad installiert, sondern auf einer Daten-Partition. Dort befindet sich auch ein weiteres Verzeichnis mit den mail-accounts.
Also das Programm ist auf der Daten-Partition, wenn ich das jetzt richtig verstanden habe. Somit stellt sich die Frage, ob dort Benutzer das Recht zum Ausführen haben.
Frank wrote: Ich hatte die Vermutung, dass es jetzt Probleme mit den Zugriffsrechten auf die Thunderbird-Verzeichnisse gibt und über die Dateifreigabe sowohl dem Benutzer als auch der Gruppe SuRunner Vollzugriff auf die entsprechenden Verzeichnisse gegeben.
Falls du das Programmverzeichnis meinst: nein, siehe oben. Falls du das Profilverzeichnis meinst: Ja, siehe meine letzte Nachricht.

Noch mal zur Erinnerung: Sollte das Profil beschädigt sein, kann es sein, daß das Umkopieren nichts bringt. Aber all das ist kein SuRun-Problem.

Nachdem ich meinen und deinen Text vor dem Absenden noch einmal gelesen habe, kommt mir folgender Gedanke: Bei all deinen Beschreibungen fehlt jegliche Angabe, daß du das TB-Profil, nachdem das Benutzerkonto vom Admin zum SuRunner (also Benutzer) migriert worden ist, an andere Stelle kopiert hast. Sollte ich daraus den richtigen Schluß ziehen, daß das Profil tatsächlich nicht kopiert worden ist, so wäre das die Erklärung für das Problem: Dir fehlen im Profil die erforderlichen Rechte. Also kopiere es um und hoffe, daß es nicht beschädigt ist; und was ganz wichtig ist, noch einmal zu Erinnerung: Das Umkopieren muß im Benutzerkonto mit eingeschränkten Rechten erfolgen, also nicht mit dem Explorer, der über SuRun gestartet ist, sonst kommst du vom Regen in die Traufe. Und noch etwas ganz wichtiges: Nach dem Umkopieren darfst du TB nicht mehr über SuRun ausführen - zumindest nicht mit diesem Profil, sonst kommst du wieder auf den Problemzustand zurück.

@Kay: Sollte meine Vermutung zutreffen, so hätten wir hier ein Beispiel dafür, daß die standardmäßig gesetzte Besitzer-Option (deren Notwendigkeit je nach Verwendungsart von SuRun klar ist) zum Bumerang geworden ist. Da diese Beispiele rar sind, weise ich hier ausdrücklich darauf hin. Frank hat klar geschrieben, daß er TB mindestens einmal über SuRun ausgeführt hat (verdachtsweise öfter). Alles, was TB bei diesem Lauf im Profil an Dateien neu erzeugt hat, liegt auf Grund der Besitzeroption (in der Standardeinstellung von SuRun) außerhalb des Schreibzugriffs durch den Benutzer (wenn Frank im Anschluß ohne SuRun TB ausführt, wie es sich ja gehört). Ein kompliziertes Problem, das aber einer Lösung bedarf. Meine Meinung dazu habe ich ja schon wiederholt dargestellt.
8 Tage später
Ich will das Thema noch mal nach vorne holen.
Hoffentlich antwortet Frank noch.
Wenn ich das nur nachvollziehen könnte.

So weit ich mich erinnere habe ich TB auch mit SuRun installiert und ohne SuRun das erste Mal gestartet.
Weil der sich beschwerte, bestimmte Dinge nicht tun zu können, habe ich ihn mit SuRun gestartet und ab dann immer die ganz oben genannte Meldung gehabt...

Jetzt versuche ich das nochmal hinzubekommen, aber es geht nicht! :huh:

Zur Besitzer-Option. SuRun könnte den Bestizer von erstellten Objekten für jedes zu startende Programm getrennt festlegen, weil der beim Erstellen des Admin-Tokens explizit angegeben werden muss.
Aber einen neuen Haken in SuRuns GUI zu platzieren oder eine neue Option in die Programmliste einzutragen erzeugt IMHO mehr Verwirrung als gut ist, oder?
Das sehe ich auch so, muß aber einräumen, daß ich mir nicht im klaren bin, wo diese Option jetzt hinkäme? Auf Seite 2 (Programmliste) oder Seite 4 (erweitert). Deswegen ist meine Antwort zur Zeit ein entschiedenes Jein.

(Und mein Umgang damit die klare Trennung zwischen SuRun für Benutzer-Programme, die ohne Admin-Rechte nicht laufen und RunAs (Ersatz) für administrative Aufgaben (wo der Besitzer dann so oder so ein Admin und nicht der SuRunner ist).

Aber in dem Zusammenhang etwas anderes, was mich schon seit einiger Zeit nervt:
Wenn ich SuRun update (statt die alte Version erst zu deinstallieren) komme ich mir jedesmal bevormundet vor, weil SuRun nicht akzeptieren mag, daß ich die Besitzer-Option nicht aktiviert habe. Ist die aktiviert, gibt es beim Update dazu nichts, doch wenn sie deaktiviert ist (was ja ganz klar eine Benutzer-Entscheidung ist, denn default will SuRun ja etwas anderes), dann muß ich bei jedem Update aufpassen, daß ich nicht übersehe, diesen Haken jedes Mal aufs neue zu entfernen. Was passieren kann, wenn man das vergißt: siehe oben.

Dringende Bitte: Nimm das bitte beim Updaten heraus. Wen der Anwender das so will, hat er entweder gute Gründe und weiß, was er tut, oder der ständige Versuch, die Option beim Updaten doch noch zu setzen wird alles, nur keinen Lerneffekt bringen.

Ach ja, vielleicht habe ich noch eine Idee, wie du das TB-Problem reproduzieren kannst:
Solange sich das TB-Profil im Konto-Profil befindet, wird das Problem nicht auftreten, weil dort der Benutzer immer Vollzugriff auch auf fremde (= Admin als Eigentümer) Dateien hat. Die meisten, die ein TB-Profil verschieben, legen es an einen Ort, wo "normale" Rechte gelten, und die sind dann halt so, daß Benutzer nur eigene Objekte schreiben und löschen können; damit schlägt dann die Besitzer-Falle wie bei Frank zu. Möglicherweise hast du jetzt zum Reproduzieren einen Ort gewählt, der im Benutzer-Profil liegt oder dem du dieselben Rechte-Konfiguration wie im Benutzer-Profil gegeben hast? Dann wirst du das Problem nicht erleben können.
Cosmo wrote: Das sehe ich auch so, muß aber einräumen, daß ich mir nicht im klaren bin, wo diese Option jetzt hinkäme?
In den "Der Befehl: <app> soll mit erhöhten Rechten ausgeführt werden."-Dialog, als Checkbox.
Bei "nicht mehr fragen" würde das Programm dann immer mit der gewählten Besitzer-Option gestartet.
Als weitere Experten-Option könnte man die "Autorität" im Token (Wer hat den Token autorisiert) auf "lokales System" setzen. Dann funktionieren auch Benutzerkontenverwaltung und Gruppenrichtlinien... Aber ich denke, dass das mehr Verwirrung, als Nutzen bringt.
Cosmo wrote: Wenn ich SuRun update (statt die alte Version erst zu deinstallieren) komme ich mir jedesmal bevormundet vor, weil SuRun nicht akzeptieren mag, daß ich die Besitzer-Option nicht aktiviert habe.
Ok, ich habe das aus dem Update rausgenommen.
Cosmo wrote: Möglicherweise hast du jetzt zum Reproduzieren einen Ort gewählt, der im Benutzer-Profil liegt oder dem du dieselben Rechte-Konfiguration wie im Benutzer-Profil gegeben hast?
Habe ich leider nicht... Meine Rechner sind mehr oder weniger identisch konfiguriert. Deshalb installiere ich Email, Java und Browser immer in einen extra Ordner (nicht C:\Programme), dorthin habe ich auch TB installiert.
Ich habe aber vergessen, auf welchem meiner Rechner das passiert ist.
Kay wrote:
Cosmo wrote: Wenn ich SuRun update (statt die alte Version erst zu deinstallieren) komme ich mir jedesmal bevormundet vor, weil SuRun nicht akzeptieren mag, daß ich die Besitzer-Option nicht aktiviert habe.
Ok, ich habe das aus dem Update rausgenommen.
Danke.
Kay wrote:Habe ich leider nicht... Meine Rechner sind mehr oder weniger identisch konfiguriert. Deshalb installiere ich Email, Java und Browser immer in einen extra Ordner (nicht C:\Programme), dorthin habe ich auch TB installiert.
Ich habe aber vergessen, auf welchem meiner Rechner das passiert ist.
'Wieso C:\Programme? Es geht doch um's Profil, ud das steckt TB nie in den Programme-Ordner.
5 Tage später
Jepp, das tut es. Ich wollte nur berichten, dass mir dasselbe passierte, als ich TB nicht in C:\Programme installierte, warum das dann nicht ging, habe ich nicht weiter erforscht.

Ich habe das Problem gestern erneut gefunden. Als ich ein neues WinXP Tablet PC Edition "recovered" habe, wurde meinem Benutzer per Voreinstellung der Zugriff auf "C:\Dokumente und Einstellungen\<User>\Anwendungsdaten" verweigert.

Deshalb funktionierte die Firefox-Installation mit SuRun, aber das Programm lief nicht.

Dort musste mir erst Vollzugriff auf %Appdata% geben, dann gings.

Ich vermute, dass TB noch andere Verzeichnisse, als sein InstallDir und %APPDATA%\Mozilla benutzt.

Process Monitor sollte das zeigen... übrigens auch bei Frank und zwar genau was da schief geht!

Wenn ich zeit habe, schaue ich mal nach.
Kay:1226483842 wrote:Ich vermute, dass TB noch andere Verzeichnisse, als sein InstallDir und %APPDATA%\Mozilla benutzt.
Ja, unter "Lokale Einstellungen\Anwendungsdaten (versteckt).
Im übrigen ist %APPDATA%\Mozilla nur ein Neben-Kriegschauplatz, das Profil liegt in %APPDATA%\Thunderbird.

Die wirklich spannende Frage lautet allerdings für mich: Was hat deinem Benutzer den Vollzugriff auf Teile seines eigenen Profils genommen? Des Interesses wegen würde es mich interessieren, welche Einträge in den Sicherheitsienstellungen dafür überhaupt noch vorhanden waren. Ach ja, welche(n) Besitzer hatte das Profil dann eigentlich?
Das Ganze ist auf einem frisch "recoverten" Windows XP Tablet PC Edition passiert.
Ich habe beim Einrichten drei zusätzliche Benutzer eingegeben, die dann vor der Installation irgendwelcher Programme von SuRun zu Nicht-Administratoren gemacht wurden.
Zwei der drei Benutzer wurden nie angemeldet, bevor SuRun sie degradiert hat.
Mein Benutzer war bereits angemeldet bevor SuRun ihn degradiert hat.

Ein paar Programme habe ich schon installiert und die liefen auch.

Nachdem FF mit SuRuns Hilfe installiert wurde habe ich ihn sich nicht selbst starten lassen.
Allerdings konnte ich ihn auch nicht starten, er ging sofort wieder zu.

Dann stellte ich fest, das mein %APPDATA% für mich nicht zugänglich war.
Meinem Benutzer war der Zugriff per ACL "verweigert" (Also richtig verboten, nicht nur nicht an!)... was genau, habe ich mir nicht gemerkt.
Ich habe den Besitz übernommen und mir Vollzugriff gegeben.
Aus die Maus.

Wer der Besitzer war und was genau verweigert wurde, habe ich leider vergessen... ich muss mir mehr aufschreiben ;-)
Hm, das bringt nichts bei der Aufklärung, wer oder was da in den Sicherheitseinstellungen so ungewöhnliches getan hat. (N.B. Mein Vertrauen wäre allerdings in den Rechner nicht mehr groß. Deutet sich da vielleicht ein Hardware-Problem mit der Festplatte oder dem RAM an?)

Aber worum es hier im Kern ja geht, ist das Problem, daß fehlende Rechte zum Beispiel Mozilla-Produkte schnell zum Erliegen bringen können. Und bei Mozilla ist diese Situation leicht vorstellbar, wenn folgendes gegeben ist:

- Mozilla-Profil außerhalb des Windows-Profils gespeichert, ohne dort die Rechte-Einstellungen explizit zu ändern.
- SuRun mit Standard-Besitzer-Option aktiviert
- Mozilla-Pogrammupdate über SuRun (und damit folglich unter Verwendung des Benutzer-Mozilla-Profils) durchgeführt. Schreibt und erstellt das Mozilla-Programm jetzt irgendwelche Dateien im Profil (zum Beispiel beim Komprimieren einer M-Box typisch), verliert der Benutzer bei normaler Benutzung des Programms jeglichen Schreibzugriff - mit allen möglichen Konsequenzen.

Deshalb warne ich davor, als SuRunner zu installieren und upzudaten. Tut man das nicht, gibt es auch keinen Grund für die SuRun-default-Besitzeroption.

Wer Installationen / Updates durchführen will, ohne ins Admin-Konto zu wechseln (was ich klar empfehle), kann immer noch den SuRun-Ersatz für RunAs verwenden; dafür wird die Änderung der Besitzer-Option nicht benötigt, hätte aber in dem genannten Fall auch keine (zumindest unmittelbare) Auswirkung, weil dann ja auf das Mozilla-Profil des Admins zugegriffen würde.
Cosmo wrote: Hm, das bringt nichts bei der Aufklärung, wer oder was da in den Sicherheitseinstellungen so ungewöhnliches getan hat. (N.B. Mein Vertrauen wäre allerdings in den Rechner nicht mehr groß. Deutet sich da vielleicht ein Hardware-Problem mit der Festplatte oder dem RAM an?)
An einen Hardware-Defekt glaube ich nicht. Rechte werden bei NTFS IMO in der MFT gespeichert - ein Plattendefekt im Bereich der MFT dürfte aber kaum nur die Rechte betreffen, vielmehr würde ich erwarten, daß auch die Datei- und Verzeichnisstrukturen was abbekommen. Das müßte aber auffallen - zumal Windows beim Rechnerstart merken sollte, daß MFT und Backup-MFT nicht mehr identisch sind, das sollte einen Startup-Checkdisk auslösen. RAM-Defekt wäre möglich, aber meist führt der nebenbei auch zu vermehrten Bluescreens, das sollte dann doch auffallen.

Wie das Rechte-Durcheinander zustandekam, würde mich auch interessieren. Eigentlich sollte es sowas ja nicht geben...

Was die Installation als SuRunner angeht, stimme ich Dir zu, die Erfahrung habe ich auch gemacht. Mit den Rechten hat man schnell Malheur, wenn man nicht aufpaßt. Die Installation als Admin oder mit der RunAs-Variante ist hier die sichere Variante.
Cosmo wrote: Hm, das bringt nichts bei der Aufklärung, wer oder was da in den Sicherheitseinstellungen so ungewöhnliches getan hat. (N.B. Mein Vertrauen wäre allerdings in den Rechner nicht mehr groß. Deutet sich da vielleicht ein Hardware-Problem mit der Festplatte oder dem RAM an?)
Das Gerät ist ein eine Woche altes Lenovo X200t (Notebook-Tablet-Convertible).
Die Hardware scheint sehr gut gebaut zu sein, nur die Software ist durchweg mittelmäßig und wenig durchdacht. Besonders das vorinstallierte Vista hat mich dazu bewogen, das beigelegte XP zu installieren.
Cosmo wrote: * Mozilla-Pogrammupdate über SuRun (und damit folglich unter Verwendung des Benutzer-Mozilla-Profils) durchgeführt. Schreibt und erstellt das Mozilla-Programm jetzt irgendwelche Dateien im Profil (zum Beispiel beim Komprimieren einer M-Box typisch), verliert der Benutzer bei normaler Benutzung des Programms jeglichen Schreibzugriff - mit allen möglichen Konsequenzen.
Das ist bisher bei mir nie der Fall gewesen.
Normalerweise erben Ordner die Rechte des übergeordneten Ordners, nur die Besitzer-Option ist anders.
Also sollte im eigenen %APPDATA% jeder Ordner und jede Datei, egal von wem erstellt, die Berechtigung von %APPDATA%, also Vollzugriff für den Benutzer, haben.
Die Besitzeroption ist nur hilfreich, wenn ein Programm explizit die ACL verändert, dann kann man sich wieder Rechte verschaffen.

Auf all meinen PC hat %APPDATA% als Besitzer die Administratoren-Gruppe, aber ich habe dennoch Vollzugriff.
Was TB da genau verzapft hat, weiß ich leider nicht mehr, weil ich mir nicht die Zeit nahm, das nachzuvollziehen.

Es ist auch möglich, dass die Recovery Mist gebaut und meinem %APPDATA%-Ordner die falschen Berechtigungen verpasst hat. (Ich dachte ich wäre in Linux! Eineinhalb Stunden durfte ich mir in der Windows-Oberfläche Installations-Perl-Scripte ansehen... ein Wunder dass das überhaupt ging!)

Zu SuRuns "Starte als Admin"-Bestätigungs-Dialog:
Ich werde wohl einbauen, dass man dort auch einen anderen Admin wählen kann, dessen Kennwort man dann eingeben muss und speichern kann... dann hat man SuRun und RunAs in einem.
Kay wrote:
Cosmo wrote: * Mozilla-Pogrammupdate über SuRun (und damit folglich unter Verwendung des Benutzer-Mozilla-Profils) durchgeführt. Schreibt und erstellt das Mozilla-Programm jetzt irgendwelche Dateien im Profil (zum Beispiel beim Komprimieren einer M-Box typisch), verliert der Benutzer bei normaler Benutzung des Programms jeglichen Schreibzugriff - mit allen möglichen Konsequenzen.
Das ist bisher bei mir nie der Fall gewesen.
Normalerweise erben Ordner die Rechte des übergeordneten Ordners, nur die Besitzer-Option ist anders.
Also sollte im eigenen %APPDATA% jeder Ordner und jede Datei, egal von wem erstellt, die Berechtigung von %APPDATA%, also Vollzugriff für den Benutzer, haben.
Innerhalb von APPDATA (ohne den spziellen Fehler deines Lenovo) ist das kein Problem. Deshalb hatte ich ja 3 Bedingungen (die als logisch UND zu verstehen sind) angegeben gehabt, unter anderem, daß das Mozilla-Profil an einen Ort außerhalb des Windows-Benutzer-Profils verlegt wird.

Innerhalb des eigenen Windows-Profils hat der Benutzer immer Vollzugriff, egal wem die Datei gehört und wer sie geschrieben hat (Ausnahme: Datei ist in das Profil hinein verschoben worden). Aber sobald der Speicherort außerhalb des Windows-Profils liegt ist das Problem nur noch eine Frage der Zeit (beim Update über Surun). Und der Fall TB ist deswegen so Praxis-relevant, weil ein TB-Profil (je nachdem, wie sehr die Leute ihre Mailboxen aufräumen) leicht in die GB wachsen kann, und wenn die Systempartition (auf der sich ja in 99% aller Fälle auch die "Dokumente und Einstellungen" befinden zu knapp bemessen ist, dann verschieben die Leute das TB-Profil halt aus dem Windows-Profil heraus.
Kay wrote: Auf all meinen PC hat %APPDATA% als Besitzer die Administratoren-Gruppe, aber ich habe dennoch Vollzugriff.
Ersteres ist nicht normal; normal ist, daß der jeweilige Benutzer der Besitzer ist. Solltest du mal untersuchen, was da noch mehr ungewöhnliches passiert. Vielleicht, weil du Benutzer zu SuRunnern machst, bevor das Konto physisch existiert?
Kay wrote:Es ist auch möglich, dass die Recovery Mist gebaut und meinem %APPDATA%-Ordner die falschen Berechtigungen verpasst hat.
Das ist natürlich auch denkbar, dann ist das Image wohl reif für die Tonne.
Kay wrote:Zu SuRuns "Starte als Admin"-Bestätigungs-Dialog:
Ich werde wohl einbauen, dass man dort auch einen anderen Admin wählen kann, dessen Kennwort man dann eingeben muss und speichern kann... dann hat man SuRun und RunAs in einem.
Muß ich erst sehen, so habe ich nicht die rechte Vorstellung, wie du das meinst.
Cosmo wrote:
Kay wrote: Auf all meinen PC hat %APPDATA% als Besitzer die Administratoren-Gruppe, aber ich habe dennoch Vollzugriff.
Ersteres ist nicht normal; normal ist, daß der jeweilige Benutzer der Besitzer ist. Solltest du mal untersuchen, was da noch mehr ungewöhnliches passiert. Vielleicht, weil du Benutzer zu SuRunnern machst, bevor das Konto physisch existiert?
So, ich habe das jetzt zum Testen mal so gemacht und es ist in der Tat (und keineswegs überraschend) so, daß das gesamte Profil zum Besitz der Administratorengruppe wird, wenn man einen Benutzer zum SuRunner macht, bevor man das Windows-Profil erstellt. Zwar behält der betreffende Benutzer seinen Vollzugriff, doch wenn jetzt - wie offensichtlich bei dir, Kay, geschehen - eine andere Sache falsch läuft, wird es übel - und das nicht nur für TB. Möglicherweise könnte der gesamte Current_User-Teil der Registrierung unbrauchbar werden und damit Windows komplett scheitern.

Ich rate dringend davon, ab, einen Benutzer zum SuRunner zu machen, der sich nicht zumindest einmal lokal in seinem Konto angemeldet hat. (Wenn die SuRun-Standard-Besitzeroption abgeschaltet wird, dürfte das Problem wohl auch nicht passieren, das aber nur so nebenbei.)

Die Frage ist natürlich, was ist, wenn man auf einem neuen System SuRun installiert und die gesicherte Konfiguration importiert, bevor die Benutzer eingerichtet und physisch existent sind? Im Augenblick habe ich nur folgende Antwort: Es ist falsch, seinen Rechner zum Arbeiten als Admin zu betreiben und es ist genauso falsch, Benutzer zu SuRunnern zu machen, so lange sie noch nicht existieren. Jeder dieser Fehler wird bestraft. Notfalls muß man nach einem Import in SuRun noch nicht als Windows-Benutzer eingerichtete SuRunner wieder entfernen.
10 Tage später
Ich habe auf die Schnelle einen "Benutzer..."-Knopf in 1.2.0.6 Beta 6 eingebaut. Da kann man "Starte als Administrator"-Programme auch als anderer Benutzer ausführen, also auch als echter Administrator.

Ich brauche Feedback ;-) Wie findest Du das?
Eine Antwort schreiben…
Impressum, Datenschutz