Drag & Drop mit aktiven UAC

[stOrM]

Hi,
ich hab da mal eine Frage zu Ole Drag & Drop in Verbindung mit Windows Vista oder Höher...
Bei mir schlägt gerade UIPI (User Interface Privilege Isolation) zu, da ich einem kleinen Tool von mir Drag & Drop spendieren wollte.

Das Ding hier ist, Drag und Drop funktionieren auch prächtig bis ich mein Tool mit erhöhten Rechten ausführe, was ich leider muss, da führt kein Weg dran vorbei.

Nun dachte ich mir gut, wenn UIPI mich schon nervt, erschlag ich das halt halbwegs über ChangeWindowMessageFilterEx (Denkste!) denn als ich das ganze in mein Tool eingebunden hatte viel mir ein das Ole Drag & Drop ja keine Messages eher Callbacks verwendet. Nun steh ich da

Hat jemand eine Idee wie ich trotzdem das Drag & Drop realisieren kann ohne!!! UAC abzuschalten?
Kann auch Dirty sein Hauptsache beides geht halt also Tool elevated inkl. Drag & Drop

Viele Grüße
s!

[himitsu]

Ist das nicht auch ohne UAC verboten?

Fakt ist nunmal, daß Messages von Anwendungen mit niedrigeren Rechten nicht an welche mit höheren Rechten verschickt werden dürfen und daran läßt sich nichts ändern.

[stOrM]

Naja wenn die Anwendung nicht mit erhöhten Rechten gestartet wird funzt das Drag & Drop wie gewohnt, mit halt nicht...

[himitsu]

Mir wäre es ja auch lieb gewesen, wenn man gewisse Messages freischalten könnte und nicht gleich alles gesperrt wäre.
Aber MS hat das leider nicht so eingerichtet.

Und da das eine Sicherheitsmaßnahme ist, wäre es "blöd", wenn man dieses leicht umgehen könnte.

[stOrM]

Naja der trouble fängt ja schon da an das es bei dem Drag & Drop nicht wirklich Messages gibt ...
MS hat ja die Möglichkeit geschaffen Messages wieder freizuschalten nur hats da leider keinen Sinn wenn die gar nicht erst generiert werden

[himitsu]

Ich dachte Drag&Drop arbeitet über Messages, zusammen mit dem Clipboard.

Die Steuerung über Messages und die Dateiliste liegt in der Zwischenablage.

[lbccaleb]

Zitat von himitsu:

Ist das nicht auch ohne UAC verboten?

Fakt ist nunmal, daß Messages von Anwendungen mit niedrigeren Rechten nicht an welche mit höheren Rechten verschickt werden dürfen und daran läßt sich nichts ändern.

1 Antwort später:

Zitat von stOrM:

Naja wenn die Anwendung nicht mit erhöhten Rechten gestartet wird funzt das Drag & Drop wie gewohnt, mit halt nicht...

Da hat wohl Jemand nicht alle Beiträge verarbeitet

[stOrM]

Zitat von Bummi:

@himitsu
ich hatte ihn so verstanden, dass sein Programm nur Probleme hat wenn es mit Administratorrechten ausgeführt wird....

So siehts aus, entweder Drag & Drop oder, mit erhöhten Rechten beides nada

Fakt ist nunmal, daß Messages von Anwendungen mit niedrigeren Rechten nicht an welche mit höheren Rechten verschickt werden dürfen und daran läßt sich nichts ändern.

Hatte ich im ersten Post ja bereits erwähnt das UIPI da zuschlägt, wie auch das MS ja eine Funktion spendiert hat für diesen Fall um trotzdem an gewisse Messages zu kommen, nur klappt das halt nich wenn es sich um Sachen handelt die keine Messages generieren und genau da liegt ja das Problem!

Delphi-Quellcode:

  ChangeWindowMessageFilterEx(Handle, WM_DROPFILES, MSGFLT_ADD, nil);
  ChangeWindowMessageFilterEx(Handle, WM_COPYDATA, MSGFLT_ADD, nil);
  ChangeWindowMessageFilterEx(Handle, WM_COPYGLOBALDATA, MSGFLT_ADD, nil);

Wären lt. diversen MSN Blogs die Nachrichten die man Freischalten müsste.
Was aber keinen Einfluß hat auf:

Delphi-Quellcode:

    fDropHelper : IDropTargetHelper; //A helper that implements details for drag and drop
    function DragEnter(const dataObj: IDataObject; grfKeyState: DWORD;
      pt: TPoint; var dwEffect: DWORD): HResult; stdcall;
    function DragOver(grfKeyState: DWORD; pt: TPoint;
      var dwEffect: DWORD): HResult; reintroduce; stdcall;
    function DragLeave: HResult; stdcall;
    function Drop(const dataObj: IDataObject; grfKeyState: DWORD; pt: TPoint;
      var dwEffect: DWORD): HResult; stdcall;

Denn oben erwähnte Messages werden hierbei nicht generiert.

[rollstuhlfahrer]

Mal ne andere Frage: Was ist, wenn du eine weitere Anwendung erstellst, die mit niedrigeren Rechten auskommt und das OLE-Drag+Drop für dich übernimmt und dann die Ergebnisse per Message/Pipe/sonstwas an das Programm mit höheren Rechten schickt? - Du musst dann quasi nur das Parent deines "kleineren" Programms umstellen und als User sollte man davon nichts mitbekommen.

Bernhard

[Dezipaitor]

Also ich habe mir das mal angesehen.
Die Möglichkeit WM_DROPFILES freizuschalten ist gut möglich und funktioniert auch. Nur darf man kein COM verwenden, wie z.B. IDropTarget.
TJvFilenameEdit und TJvDragDrop funktionierten nach dem ersten Prinzip. TJvDropTarget verwendet COM, daher funktioniert es damit nicht.

Ich habe schon die COM Einstellungen für den Prozess heruntergefahren ohne Erfolg (COM Implementation von IAccessControl). Andersherum kann man den Zugriff für Drag&Drop einschränken, d.h. COM Sicherheit nach oben schrauben.
Da IAccessControl.IsAccessAllowed im ersten Fall nie aufgerufen wird, vermute ich, dass COM schon vorher die Prüfung selbst durchführt und die Nachrichten daher erst garnicht gesendet werden.

Internet Explorer macht es so wie rollstuhlfahrer es beschrieben hat. Es gibt einen Hauptprozess und für jedes Tab einen eigenen Prozess. Wenn man nun eine Datei in den IExplorer fallen lässt, dann wird dies in einem Medium Integrity Level (MIL) Tab geöffnet. Webseiten werden jeweils in einem Low Integrity Level Tab dargestellt.
D.h. der Hauptprozess vom IE übernimmt das Drag&Drop, was ja auch funktioniert, da es im MIL ausgeführt wird. Und die Fenster selbst sind wohl Prozessübergreifend verbunden. Das sieht man im ProcessExplorer, wenn man mal die verschiedenen Bereiche mit dem FindWindow Feature anklickt. Dann sieht man, dass es jedesmal ein anderer Prozess ist.

Mit Spy sollte man keine Nachrichten sehen können, weil bei IDropTarget alles nur noch über COM Callbacks geht.