Reature Request: Rechteanforderung im Plugin Interface

[dy/dx]

... es ist ein jaaaahrelanger Wunsch von mir und ich nutze jetzt einfach mal die Gelegenheit das kund zu tun.

Ich verstehe nicht, wieso es nicht eingebaut ist, aber es waere essentiell eine API fuer Rechteverwaltung in das FS Plugin Interface einzubauen.

Es gibt so viele geniale Plugins fuer TC die ich unterm Strich nie verwende weil ich eben als User arbeite

Beispiel: Registry Plugin, DiskReader, ext2 Reader, ... All das benoetigt admin Rechte und es waere super wenn diese einfach angefordert werden wuerden, genauso wie bei normalen Dateioperationen auch.

Und mir ist klar dass das nicht einfach ist (so muessten vermutlich Teile des Plugins von TCMADM64.EXE ausgefuehrt werden).

Aber so seufze ich jedesmal wenn ich erst regedit als admin oeffnen muss



PS: TC als admin starten ist fuer mich keine Loesung.

[Dalai]

Das Problem dürfte sein, dass die doch sehr unterschiedlichen Plugins potentiell viel zu unterschiedliche Anforderungen haben, welche Befehle gerade mit erhöhten Rechten ausgeführt werden sollen. Das eine Plugin will was aus der Registry, das nächste irgendwas von Dateien (aus einem möglicherweise dem Windows unbekannten Dateisystem), das übernächste wäre dann mein Service-Plugin, das Dienste steuert usw.

PS: TC als admin starten ist fuer mich keine Loesung.

Warum nicht? Ein temporär als Admin gestarteter TC ist wohl kaum problematisch. Den kann man sogar verdammt komfortabel auf die Buttonbar/Symbolleiste oder ins Startermenü einbauen und das Startkommando mit einem führenden Stern * ausstatten (nur in der Buttonbar), damit der TC sich selbst nach Rückfrage als Admin startet. Als Parameter übergibt man den Pfad des jeweiligen Dateisystem-Plugins. Beispiel für einen Button:

Code: Select all

TOTALCMD#BAR#DATA
*%COMMANDER_EXE%
\\\Registry
totalcmd.exe



-1

MfG Dalai

[dy/dx]

Das Problem dürfte sein, dass die doch sehr unterschiedlichen Plugins potentiell viel zu unterschiedliche Anforderungen haben, welche Befehle gerade mit erhöhten Rechten ausgeführt werden sollen. Das eine Plugin will was aus der Registry, das nächste irgendwas von Dateien (aus einem möglicherweise dem Windows unbekannten Dateisystem), das übernächste wäre dann mein Service-Plugin, das Dienste steuert Wink usw.

Das ist kein Problem, denn alle diese Dinge haben die Anforderung gemeinsam dass sei Admin Rechte benoetigen. D.h.

Warum nicht?

1.) Weil es invonvenient und unelegant ist. Weil ich auch nicht einen zweiten TC oeffnen will wenn ich nach c:\windows\system32 moechte. Mit dem neuen TC muss ich dann z.B. die benoetigte Ansicht komplett manuell wiederherstellen (Verzeichnispfade, Sortierung etc.)
Was ist wenn ich eine Datei von einem ein admin benoetigendes Plugin auf ein Netzlaufwerk kopieren moechte oder auf ein "subst"-Laufwerk. Geht nicht.

2.) Meine TC Konfiguration ist in %APPDATA%/Ghisler. Da gehoert sie hin und das moechte ich so. Wenn ich TC aber als admin starte hat der seine eigene Konfiguration.

Wenn man akzeptiert dass es super ist, dass TC Dateioperationen als admin ausfuehren kann dann impliziert es aus Usersicht das gleiche fuer Plugins. Hier gibt es naemlich keine Unterschiede! Und nochmal: Ich habe bereits geschrieben dass die Umsetzung vielleicht nicht leicht ist, aber sicher moeglich - und auch so, dass man Rueckwartskompatibilitaet gewaehrleistet.

[Dalai]

Das ist kein Problem, denn alle diese Dinge haben die Anforderung gemeinsam dass sei Admin Rechte benoetigen.

Ja sicher. Aber trotzdem sind die Anforderungen viel zu unterschiedlich. Ich gebe mal ein Beispiel für mein Services2-Plugin. Ich bin dabei, hierfür ein Admintool zu schreiben, das analog zu dem TC-eigenen arbeitet. Nun muss dieses Tool aber schon allein zum Steuern von Diensten mindestens drei Befehle haben/kennen (starten, stoppen und neu starten, eigentlich kommen noch zwei weitere dazu, nämlich pausieren und fortsetzen). Zum Ändern von Diensteinstellungen sind nochmals unzählige Befehle nötig (Anzeigename, Beschreibung, Desktop-Interaktion, Starttyp usw). All diese Einzelheiten müssten dann noch für andere Plugins umgesetzt werden, die auf die Registry, auf Dateien oder auf Sektoren der Platte zugreifen (Diskimage-Plugins oder ähnliche!). Du siehst also: nur weil die Plugins alle die Gemeinsamkeit haben, Adminrechte zu brauchen, müsste das Admintool viel zu viel können, um es allen recht zu machen (und mit sehr hoher Wahrscheinlichkeit werden einige nicht zufriedengestellt).

2.) Meine TC Konfiguration ist in %APPDATA%/Ghisler. Da gehoert sie hin und das moechte ich so. Wenn ich TC aber als admin starte hat der seine eigene Konfiguration.

Dann füge dem o.g. Button noch den Parameter /I=%AppData%\Ghisler\wincmd.ini hinzu und schon kannst du dieselbe Konfiguration nutzen.

Wenn man akzeptiert dass es super ist, dass TC Dateioperationen als admin ausfuehren kann [...]

Aber bei Weitem nicht alle. Dummerweise fällt mir gerade keine Operation ein, bei der das Admintool versagt. Ich hab es vor einiger Zeit aufgegeben, es zu nutzen, weil immer irgendwas nicht ging, und nutze daher schon immer eine TC-Instanz als Admin, wenn nötig.

Nur damit ich nicht falsch verstanden werde: Klar wäre es schön, wenn die Plugin-Schnittstelle sowas hätte (würde mir das Schreiben eines eigenen Admintools ersparen ), aber ich halte das für nicht machbar - ich lasse mich aber gern überzeugen, wenn ich etwas Funktionierendes in der Richtung sehe.

MfG Dalai

[Horst.Epp]

...
2.) Meine TC Konfiguration ist in %APPDATA%/Ghisler. Da gehoert sie hin und das moechte ich so. Wenn ich TC aber als admin starte hat der seine eigene Konfiguration.

Das ist für einen Admin wohl die unpraktischste Stelle für eine TC Konfig
auch wenn ein unsinniger Microsoft Standard das so vorsieht.
Da man ja wohl nur selten Admin Rechte braucht, ist es wesentlich sinnvoller,
die Konfig im Programmverzeichnis oder an anderer zentraler Stelle zu haben,
und zwar unabhängig davon als was man gerade arbeitet.
Wenn ich in meinem TC eine Admin Instanz starte, dann hat die selbstverstaendlich die gleichen Pfade wie die startende Instanz.
Dazu gibt es schliesslich entsprechende Command line Argumente.
Aber wenn man es gerne kompliziert machen will ...

[dy/dx]

Aber trotzdem sind die Anforderungen viel zu unterschiedlich.

?
Eine "Aktion" benoetigt admin Rechte oder eben nicht.
Und falls ja, kann diese eben angefordert werden und Code wird dann durch TCMD im priviligierten Modus ausgefuhert (nochmal: "einfach" ist das sicher nicht)

Ich gebe mal ein Beispiel für mein Services2-Plugin.
Ich bin dabei, hierfür ein Admintool zu schreiben, das analog zu dem TC-eigenen arbeitet. Nun muss dieses Tool aber schon allein zum Steuern von Diensten mindestens drei Befehle haben/kennen (starten, stoppen und neu starten, eigentlich kommen noch zwei weitere dazu, nämlich pausieren und fortsetzen). Zum Ändern von Diensteinstellungen sind nochmals unzählige Befehle nötig (Anzeigename, Beschreibung, Desktop-Interaktion, Starttyp usw). All diese Einzelheiten müssten dann noch für andere Plugins umgesetzt werden, die auf die Registry, auf Dateien oder auf Sektoren der Platte zugreifen (Diskimage-Plugins oder ähnliche!). Du siehst also: nur weil die Plugins alle die Gemeinsamkeit haben, Adminrechte zu brauchen, müsste das Admintool viel zu viel können, um es allen recht zu machen (und mit sehr hoher Wahrscheinlichkeit werden einige nicht zufriedengestellt).

Nein, das versteh ich nicht.
Du hast eine Aktion die benoetigt admin Rechte.
Derzeit ist es so, dass du sie einfach ausfuehrst und es schlaegt fehl falls du diese nicht hast.
In einem neuen Interface sagst du Tcmd: "Ich benoetige fuer eine Aktion admin Rechte". Tcmd holt diese normal ein (TCMDADM.exe) und startet dann die entsprechende Funktion als admin. Wie das genau am besten geht hab ich mir nicht durchueberlegt, aber eine Methode waere es die Funktion zu exportieren und TCMDADM fuehrt dies als admin aus; Kommunikation lauft dann ueber IPC.

Dann füge dem o.g. Button noch den Parameter /I=%AppData%\Ghisler\wincmd.ini hinzu und schon kannst du dieselbe Konfiguration nutzen.

Ich schaff' es einfach nicht.
Selbst wenn ich

Code: Select all

c:\Program Files\totalcmd>TOTALCMD64.EXE /i=c:\Users\user\AppData\GHISLER\wincmd.ini

von der Kommandozeile starte (als gleicher User) bekomme ich nur die Default einstellungen.

Wenn das funktioniert, waere es zumindest ein kreativer Hack Kann man den vielleicht so erweitern dass z.B. die Links/Rechts Pfade auch uebergeben werden?

Wenn ich dann als normaler User haette:
Links: c:\temp
Rechts: \\\Registry\HKEY_LOCAL_MACHINE\Software

dann wuerde TCMD als admin gestartet, mit der gleichen Config und den gleichen Panels, nur eben als admin.
Ich hoffe, dass admin dann auf %APPDATA% des Users zugreifen kann ...

Nur damit ich nicht falsch verstanden werde: Klar wäre es schön, wenn die Plugin-Schnittstelle sowas hätte (würde mir das Schreiben eines eigenen Admintools ersparen Wink), aber ich halte das für nicht machbar - ich lasse mich aber gern überzeugen, wenn ich etwas Funktionierendes in der Richtung sehe.

Ok, vielleicht hab ich Glueck und Christian liest hier mit und baut echt irgendwann eine Schnittstelle ein

Es ist natuerlich auch klar dass die blosse Schnittstelle nur die halbe Miete ist, die Plugins muessten diese dann auch verwenden ...

[Dalai]

Nein, das versteh ich nicht.

Dann solltest du vielleicht ein Dateisystem-Plugin schreiben , dann weißt du, warum das so ist. Ich erkläre es mal etwas genauer: TC läuft als Nutzer, das Admintool läuft als Admin. Welche Möglichkeiten haben nun diese beiden Prozesse, miteinander zu kommunizieren? Eine simple Nachricht (SendMessage/PostMessage) ist nicht möglich, weil Windows das aus Sicherheitsgründen verbietet, Nachrichten an priviligierte Prozesse zu schicken. Was bleibt also für IPC (Interprocess Communication)? Pipes (und noch ein paar andere). Und über diese Pipe muss nun der TC dem Admintool erstmal sagen, worum es geht (Registry, Dateien, Dienste, whatever), was das Admintool machen soll (löschen, anlegen, ändern usw).

Du hast eine Aktion die benoetigt admin Rechte.
Derzeit ist es so, dass du sie einfach ausfuehrst und es schlaegt fehl falls du diese nicht hast.
In einem neuen Interface sagst du Tcmd: "Ich benoetige fuer eine Aktion admin Rechte". Tcmd holt diese normal ein (TCMDADM.exe) und startet dann die entsprechende Funktion als admin.

Ne, so einfach ist es eben nicht. Die ganze Logik muss nochmals in dem Admintool stecken, und die beiden Prozesse müssen miteinander kommunizieren.

Dann füge dem o.g. Button noch den Parameter /I=%AppData%\Ghisler\wincmd.ini hinzu und schon kannst du dieselbe Konfiguration nutzen.

Ich schaff' es einfach nicht.
Selbst wenn ich

Code: Select all

c:\Program Files\totalcmd>TOTALCMD64.EXE /i=c:\Users\user\AppData\GHISLER\wincmd.ini

von der Kommandozeile starte (als gleicher User) bekomme ich nur die Default einstellungen.

Wird denn diese wincmd.ini im normalen Betrieb überhaupt verwendet? Siehe Menü Hilfe > Über TC. Im Prinzip funktioniert mein Hinweis einwandfrei (gerade getestet):

Code: Select all

TOTALCMD#BAR#DATA
*%COMMANDER_EXE%
/i="%%Temp%%\fresh.ini" \\\Registry
totalcmd.exe



-1

Wenn das funktioniert, waere es zumindest ein kreativer Hack Kann man den vielleicht so erweitern dass z.B. die Links/Rechts Pfade auch uebergeben werden?

Klar, siehe Parameter /L= und /R= in der TC-Hilfe, Abschnitt 4.a) Kommandozeilenparameter.

dann wuerde TCMD als admin gestartet, mit der gleichen Config und den gleichen Panels, nur eben als admin.
Ich hoffe, dass admin dann auf %APPDATA% des Users zugreifen kann ...

Ein Admin hat - sofern nichts an den Zugriffsrechten angepasst wurde - standardmäßig Zugriff auf alle Verzeichnisse eines Windows-Systems inkl. aller Nutzerverzeichnisse, abzüglich einiger Spezialverzeichnisse wie "System Volume Information". Aber nur damit es gesagt wird: die Umgebungsvariable %AppData% wird schon vorher vom bereits laufenden TC aufgelöst; die neu gestartete TC-Instanz bekommt also einen absoluten Pfad zur wincmd.ini übergeben.

MfG Dalai

[dy/dx]

Dann solltest du vielleicht ein Dateisystem-Plugin schreiben ...

Kommt vielleicht unerwartet: Habe ich! [ist aber 10 Jahre her]
Ich habe fuer viele Programme Plugins geschrieben und die WinApi entsprechend gehackt Wie gesagt: Ich weiss dass es nicht leicht ist aber ich weiss dass es moeglich ist.

Die ganze Logik muss nochmals in dem Admintool stecken,

Auch das stimmt nicht, die kann ebenfalls die API wegabstrahieren (aehnlich wie bei Systems Calls Teile im Kernelmode und Teile im Usermode laufen koennen).

Wird denn diese wincmd.ini im normalen Betrieb überhaupt verwendet? Siehe Menü Hilfe > Über TC. Im Prinzip funktioniert mein Hinweis einwandfrei (gerade getestet):

Ok, danke jetzt hab ich den Fehler gefunden, weiss aber nicht wieso er auftritt: Im aufgerufenen TC steht als verwendete INI file: "PPDATAGHISLER\wincmd.ini". Die Variable %APPDATA% wird vom TC also nicht aufgeloest! Wenn ich stattdessen zwei verwende (also "/I=%%APPDATA%%\GHISLER\wincmd.ini"), wird dem TC die Variable uebergeben und dann wird AppData natuerlich als c:\Users\admin\... expandiert ...

Klar, siehe Parameter /L= und /R= in der TC-Hilfe, Abschnitt 4.a) Kommandozeilenparameter.

Danke.
Das Auslesen scheint etwas kompliziert zu werden, die Beschreibung zu %X, %P, %T ist etwas konfus aber ich probiers mal ....

/EDIT: Ich sehe, ich kann einfach %COMMANDER_INI% verwenden. Aber jetzt hab ich das Problem dass ich die Plugins nicht sehe, da ich diese ja auch benutzerspezifisch in APPDATA installiert hab (auch das will ich so).

Ein Ausweg koennte sein, dass ich mir selbst %COMMANDER_CONF% erstelle und alles nach %COMMANDER_CONF% aufloese statt nach %APPDATA%\Ghisler ...

[Dalai]

Ok, danke jetzt hab ich den Fehler gefunden, weiss aber nicht wieso er auftritt: Im aufgerufenen TC steht als verwendete INI file: "PPDATAGHISLER\wincmd.ini". Die Variable %APPDATA% wird vom TC also nicht aufgeloest! Wenn ich stattdessen zwei verwende (also "/I=%%APPDATA%%\GHISLER\wincmd.ini"), wird dem TC die Variable uebergeben und dann wird AppData natuerlich als c:\Users\admin\... expandiert ...

Ja, das hab ich vielleicht vergessen zu erwähnen: Prozentzeichen und das nachfolgende Zeichen werden vom TC als entsprechende Platzhalter interpretiert, also %P, %L usw. Kann sogar sein, dass das selbst dann passiert, wenn der Platzhalter gar nicht existiert. Prozentzeichen für Umgebungsvariablen müssen daher verdoppelt werden.

MfG Dalai

[dy/dx]

Ja, das hab ich vielleicht vergessen zu erwähnen: Prozentzeichen und das nachfolgende Zeichen werden vom TC als entsprechende Platzhalter interpretiert, also %P, %L usw. Kann sogar sein, dass das selbst dann passiert, wenn der Platzhalter gar nicht existiert. Prozentzeichen für Umgebungsvariablen müssen daher verdoppelt werden.

Ok, das macht Sinn. Aber dann, wie gesagt, wird die Variable nicht von TCMD expandiert sondern direkt weitergegeben wo sie nicht/anders definiert sein koennte. Kann man TC dazu bringen die Variable vor dem Aufruf selbst aufzuloesen?


/EDIT: Was eigentlich viel besser waere: Gibt es nicht einfach die Moeglichkeit den TC Prozess wie er ist nochmal aufzurufen aber mit anderen Rechten? Dann wuerde sich das alles eruebrigen! Sowas wie "runas /env" ...

/EDIT2: Optimalerweise sollte das natuerlich nicht mit "runas" laufen sondern mit dem normalen Dialog der auch mit "*"-Aufruf kommt. Aber selbst wenn ich es mit runas /env versuche sehe ich wieder sonderbare Effekte: Der als admin laufende TC verwendet nun definitiv die Nutzer wincmd.ini (in "About Total Commander" wird als INI Datei c:\Users\user\AppData\Local\Ghisler\wincmd.ini angegeben), trotzdem verwendet der TC durchwegs Default Einstellungen. Das aendert sich auch nicht, wenn ich die INI Datei mit "/I=" explizit mit uebergebe. An was kann das liegen?

[Dalai]

Aber dann, wie gesagt, wird die Variable nicht von TCMD expandiert sondern direkt weitergegeben wo sie nicht/anders definiert sein koennte.

Mmh, sieht so aus.

Kann man TC dazu bringen die Variable vor dem Aufruf selbst aufzuloesen?

Nun, entweder keine Variablen benutzen oder ... ich weiß es auch nicht. Selbst wenn man eine CMD dazwischenschaltet, wird %AppData% ja aufgrund des RunAs (das der TC ja macht) erst später aufgelöst.

MfG Dalai

[Sir_SiLvA]

Ok, das macht Sinn. Aber dann, wie gesagt, wird die Variable nicht von TCMD expandiert sondern direkt weitergegeben wo sie nicht/anders definiert sein koennte. Kann man TC dazu bringen die Variable vor dem Aufruf selbst aufzuloesen?

würdest du mal erklären wie eine system variable wie appdata undefiniert sein soll?

und anstatt das wir unsere Glaskugel raussuchen müssen poste doch lieber deinen definierten knopf?

[Dalai]

würdest du mal erklären wie eine system variable wie appdata undefiniert sein soll?

Oh, das geht ganz einfach, jedenfalls auf Windows-Systemen bis einschließlich XP: Starte einfach irgendein Programm - vorzugsweise natürlich den TC - via RunAs (oder Ausführen als) und schon ist diese Variable in dem gestarteten Prozess (und in allen von ihm gestarteten Prozessen) nicht existent. Damit funktionieren natürlich alle Dinge nicht mehr, die diese Variable verwenden. Nicht, dass das hierfür unbedingt relevant wäre, ich wollte es nur mal erwähnt haben . MS hat diesen Bug mit Vista (oder Win7) endlich behoben.

MfG Dalai

[dy/dx]

würdest du mal erklären wie eine system variable wie appdata undefiniert sein soll?

Ich spreche nicht nur von *System*variablen sondern ENV-vars.
Hier:
1.) User hat Variable "COMMANDER_CONF" definiert.
2.) Variable "APPDATA" zeigt auf c:\users\User\AppData\Roaming"

User startet Total Commander als admin mit "/I=%%COMMANDER_CONF%%\wincmd.ini" oder "/I=%%APPDATA%%\Ghisler\wincmd.ini".

Im ersten Fall ist sie gar nicht definiert.
Im zweiten Fall falsch (zeigt also nach c:\users\admin statt c:\users\user).

Das koennte geloest werden wenn TCMD die Variablen vor dem Aufruf expandieren wuerde.

[dy/dx]

Ok, ich versuche es nochmal mit dieser Frage:

Aber selbst wenn ich es mit runas /env versuche sehe ich wieder sonderbare Effekte: Der als admin laufende TC verwendet nun definitiv die Nutzer wincmd.ini (in "About Total Commander" wird als INI Datei c:\Users\user\AppData\Local\Ghisler\wincmd.ini angegeben), trotzdem verwendet der TC durchwegs Default Einstellungen. Das aendert sich auch nicht, wenn ich die INI Datei mit "/I=" explizit mit uebergebe. An was kann das liegen?

Wenn ich Total Commander als admin aus Total Commander starte, kann ich problemslos nach c:\Users\user wechseln.

Wenn ich ihn aber mit runas starte (runas /user:admin totalcmd64.exe), erhalte ich vor dem Wechseln nach c:\users\user eine UAC Meldung zum Abnicken.

Das ist also der Grund wieso Total Commander die ini nicht laedt wenn ich ihn ueber "runas /env" starte.

Was macht "runas.exe" anders als "Als Administrator ausfuehren" im Total Commander?

Ich habe bereits einen Feature Request geschrieben dem "Als Administrator ausfuehren" auch die option zu uebergeben das gleiche Environment zu verwenden (i.e., "/env"-Switch von runas).

Unabhaengig davon: Gibt es eine Moeglichkeit ein Programm vom Total Commander als admin zu starten, das gleiche Environment zu verwenden und trotzdem keine UAC Meldungen mehr zu bekommen?