'Run' führt Exe NICHT aus die Adminrechte benötigt, 'ShellExecute' tut's

Professor Bernd

Mein Script läd eine Datein ("AutoIt-v3-Setup.exe") aus dem Internet, speichert sie in einem Unterordner des User-Temp-Verzeichnisses und soll sie dann starten. Die Setup.exe benötigt Adminrechte, die sie selbst nach ihrem Start anfordert.

Jedoch läuft der Befehl Run($sTargetDir & "Hallo Welt.exe", $sTargetDir) ins Leere, er macht rein gar nichts. Es kommt keine UAC-Meldung, keine Fehlermeldung, einfach nichts.

Mit ShellExecute funktioniert alles wie gewünscht: Die Setup.exe wird gestartet und fordert Adminrechte => das UAC-Abfrage-Vollbild erscheint. Nach dem Klicken auf Ja oder Nein beendet sich mein Script, das scheinbar von der UAC-Abfrage blockiert wurde. (Ist das so?)

Wie dem auch sei, mit ShellExecute habe ich eine Lösung, aber ich würde doch gerne wissen, warum "Run" NICHT funktioniert.

alpines AspirinJunkie

In der Shoutbox hatte ich die Frage gestellt, aber die Antworten wurden recht umfangreich, weshalb ich diesen Thread erstellt habe. Damit ich nicht durcheinander werfe, was verschieden User geantwortet haben, hier lediglich 1 Zitat aus der Shoutbox:

Zitat von Aspirinjunkie

Wenn uac Abfrage kommt wird von der exe erhöhte Rechte angefordert. Wenn dein eigenes Skript kein #RequireAdmin hat dann bringt shellexecute die uac Abfrage und Run verwirft den Aufruf einfach wegen mangelnder Rechte. Also ganz normales Verhalten.

**alpines**

Run ist das abgespeckte Pendant zu RunAs, und dort kannst du direkt Zugangsdaten für Domäne, Konten und Passwörtern abgeben.

Ich schätze, auch aus diesem Grund wird kein UAC-Prompt getriggert, da es sonst in AutoIt keine Möglichkeit gäbe, ein Setup zu starten ohne den User damit zu belästigen, für den Fall, dass solch ein Zugriff nicht möglich ist.

ShellExecute funktioniert ja auch komplett anders, es verwendet die ShellExecute API von Windows und diese zeigt dir automatisch das UAC-Prompt an, eben weil es über die Shell läuft und die Anwendung nicht direkt geladen wird. Das bringt auch einige andere Implikationen mit sich als nur die UAC-Prompt.

Professor Bernd

Was ich nicht verstehe ist, dass Run die Setup.exe nicht startet.

Aus der AutoIt Hilfe

Run: Startet ein externes Programm.

RunWait: Startet ein externes Programm und pausiert die Ausführung des Autoit-Skripts, bis das externe Programm beendet ist.

Somit heißt das implizit, dass Run die Ausführung des Autoit-Skripts NICHT pausiert.

Meine Überlegung:

Mein Script hat KEINE Adminrechte (soll es auch nicht haben) und soll per "Run" eine Setup.exe starten, NICHT warten, sondern sich selbst beenden. Die Setup.exe braucht Adminrechte, die fordert sie selbst an. Nach meinem Verständnis braucht mein Script keine Adminrechte, um ein anderes Programm zu starten. ShellExecute scheint das auch zu beweisen.

Wo ist mein Denkfehler?

**alpines**

Zitat von Professor Bernd

Was ich nicht verstehe ist, dass Run die Setup.exe nicht startet.

Zitat von Professor Bernd

Wo ist mein Denkfehler?

Es sind zwei verschiedene Paar Schuhe.

Run versucht die Datei auszuführen, es ist aber nicht möglich, da die Rechte fehlen. Der User ist nicht berechtigt die Datei auszuführen.

Ändere die Dateiattribute, dass du Vollzugriff auch ohne Adminrechte hast, und die Datei startet.

ShellExecute führt keine Datei direkt aus wie Run es tut. Du sagst mit ShellExecute nur, "hey, führe mir diese datei bitte aus".

ShellExecute versuchts und schafft es nicht, weil dir ebenfalls die Rechte fehlen, jedoch bietet dir die Shell an, die Datei auszuführen, wenn du dich als Administrator verifiziert.

Wenn du dich als Admin verifizierst, indem du auf "Ja" klickst beim UAC-Prompt, erbst du diese Rechte nicht.

Das wird auch klar wenn du versuchst mal eine GUI zu schließen die mit Adminrechten läuft, es klappt nicht, wenn du nicht auf dem selben Level oder höher bist.

Versuch mal mit Run eine txt-Datei zu starten, es klappt nicht. ShellExecute hingegen startet das zugewiesene Programm und übergibt die Datei als CLI-Parameter.

Genau das was eine Shell tun soll.

Du kannst auch dein Skript so modifizieren, dass es ohne Adminrechte startet, und wenn du welche brauchst um Programme zu starten, kannst du das "nachträglich" anfordern.

Wenn du gänzlich auf Adminrechte verzichten willst führt bei dir kein Weg drum rum ShellExecute zu verwenden oder den User das ganze selbst starten zu lassen.

Es wäre bestimmt auch möglich mit Run die @ComSpec zu starten und so das ganze zu starten, aber das läuft letzen Endes dann auch über die ShellExecute API wenn ich mich nicht täusche.

Professor Bernd

Zitat von alpines

Run versucht die Datei auszuführen, es ist aber nicht möglich, da die Rechte fehlen. Der User ist nicht berechtigt die Datei auszuführen.
...

ShellExecute führt keine Datei direkt aus wie Run es tut. Du sagst mit ShellExecute nur, "hey, führe mir diese datei bitte aus".
ShellExecute versuchts und schafft es nicht, weil dir ebenfalls die Rechte fehlen, jedoch bietet dir die Shell an, die Datei auszuführen, wenn du dich als Administrator verifiziert.

ShellExecute "open" öffnet/startet eine Datei mit dem assoziierten (was ein doofes Wort) Programm. Eine Exe wird wohl mit dem Windows Explorer assoziiert, der dann die Freundlichkeit besitzt, die UAC-Anfrage zu zeigen. - Da frage ich mich, warum Run nicht so nett ist!? Und ich frage mich, ob Run denn was anderes macht, als die Shell (den Windows Explorer) zum Starten der Setup.exe zu benutzen!?

Na egal. Ich denke, diese Informationen reichen mir erstmal. Zum Glück gibt es für solche Fälle als Lösung ShellExecute und ShellExecuteWait.

Vielen Dank euch beiden!

**alpines**

Zitat von Professor Bernd

Da frage ich mich, warum Run nicht so nett ist!? Und ich frage mich, ob Run denn was anderes macht, als die Shell (den Windows Explorer) zum Starten der Setup.exe zu benutzen!?

Das ist nicht der Sinn von Run.

Alle von Run gestarteten Anwendungen werden nicht über die Shell gestartet sondern über einen Betriebssystemaufruf, und der gestartete Prozess erbt (wenn man es nicht anders angibt) die Rechte, die das aufrufende Skript besitzt.

ShellExecute hingegen macht noch vieles im Hintergrund und zeigt dir eben diese UAC-Prompt.

Wieso sollte denn Run das selbe machen? Dann kann man sich doch direkt eine Funktion sparen.

Professor Bernd

Zitat von alpines

Alle von Run gestarteten Anwendungen werden nicht über die Shell gestartet sondern über einen Betriebssystemaufruf,

Was ist der Unterschied? Unter Windows ist die Shell doch das zuständige Programm zum ausführen von anderen Programmen. (Knoten-im-Kopf)

Zitat von alpines

und der gestartete Prozess erbt (wenn man es nicht anders angibt) die Rechte, die das aufrufende Skript besitzt.

Genau da verstehe ich nicht, warum Run nicht funktioniert. Es werden keine Adminrechte zum Aufrufen benötigt, der gestartete Prozess kann gerne die Normaluser-Rechte erben, es fordert doch die Admin-Rechte selbst an. Wenn ich die Setup.exe doppel-klicke, startet sie ja auch und fordert Admin-Rechte an.

Anders ausgedrückt. Hätte ich in meinem Script Admin-Rechte angefordert und bekommen, würde das Starten des Setups mit Run vermutlich ohne weitere UAC-Anfrage funktionieren, oder? (ungetestet)

Leider kann man nicht in den Quellcode von Run sehen, dann würde sich einiges klären.

**alpines**

Zitat von Professor Bernd

Was ist der Unterschied? Unter Windows ist die Shell doch das zuständige Programm zum ausführen von anderen Programmen. (Knoten-im-Kopf)

Wenn du Programme aus dem Explorer heraus startest ja, aber selbst die ShellExecute API führt am Ende des Tages auch nur ein Run aus.

Startest du Programme über andere Programme bist du nicht an eine Shell gebunden, du kannst auch dem Betriebssystem direkt sagen, dass ein Programm gestartet werden soll.

Die Shell startet keine Programme und lädt sie in den RAM, das tut das Betriebssystem wenn du den entsprechenden Betriebssystemaufruf verwendest.

Damit du dich mit Privilegien usw. nicht ärgern musst gibt es die ShellExecute API, die bietet dir auch noch andere Hilfestellungen damit du dich mit Run nicht rumschlagen musst.

Dafür muss die Shell auf dem System vorhanden sein, ist sie es nicht, funktioniert die API nicht. Run ist direkt im System verwurzelt, da es ein direkter Betriebssystemaufruf ist.

Dein Programm wird nicht "aufgerufen" sondern wird von Run ausgeführt, und zur Ausführung fehlen dir die Rechte.

ShellExecute führt dein Programm nicht direkt als Nachfolger mit geerbten Privilegien aus, sondern es stellt fest, dass dir die Rechte fehlen und bietet dir an, dass Programm zu starten indem du dich mit höheren Rechten authentifizierst. DU startest das Programm nicht, die Shell tuts.

Zitat von Professor Bernd

Anders ausgedrückt. Hätte ich in meinem Script Admin-Rechte angefordert und bekommen, würde das Starten des Setups mit Run vermutlich ohne weitere UAC-Anfrage funktionieren, oder? (ungetestet)

Korrekt.

Professor Bernd

Ok, ich denke, ich verstehe es soweit halbwegs. Solange ich nicht in den Quellcode von Run sehen kann, ist das Thema somit "gelöst".

Ergänzend und nur zur Info: Wenn ich Run mit dem Windows Explorer kombiniere, ist der Effekt der gleiche wie bei ShellExecute. (Das hast du ja auch sinngemäß geschrieben.)

Run('explorer "' & $sTargetDir & $sTargetFileName & '"', $sTargetDir)

Ende.

**AspirinJunkie**

Zitat von Professor Bernd

Solange ich nicht in den Quellcode von Run sehen kann, ist das Thema somit "gelöst".

ShellExecute ruft die Windows-API-Funktion >>ShellExecute<< (oder auch ShellExecuteEx) auf.

Run() ruft die Windows-API-Funktion >>CreateProcess<< auf.

Dort findet sich folgender wichtiger Hinweis:

Zitat von CreateProcess-Dokumentation

The new process runs in the security context of the calling process.

Heißt: Es ist schlicht gar nicht vorgesehen, dass das aufrufende Programm in einem anderen Security-Kontext laufen kann. Daher schlägt der Aufruf auch fehl da im derzeitigen Kontext nicht genügend Rechte für die Anforderung bereit stehen.

Edit: Achso - du wolltest ja den Quellcode zur Run()-Funktion:

Code

AUT_RESULT AutoIt_Script::Run(int nFunction, VectorVariant &vParams, uint iNumParams, Variant &vResult)
{
    STARTUPINFO                si;
    STARTUPINFOW            wsi;

    PROCESS_INFORMATION        pi;
    char                    szRun[AUT_MAX_LINESIZE+1];
    wchar_t                    *wszRun;
    char                    szDir[AUT_MAX_LINESIZE+1];
    wchar_t                    *wszDir;
    BOOL                    bRes;

    HINSTANCE                    hinstLib = NULL;
    MyCreateProcessWithLogonW    lpfnDLLProc = NULL;


    // init structure for running programs
    si.cb            = sizeof(STARTUPINFO);
    si.lpReserved    = NULL;
    si.lpDesktop    = NULL;
    si.lpTitle        = NULL;
    si.dwFlags        = STARTF_USESHOWWINDOW;
    si.cbReserved2    = 0;
    si.lpReserved2    = NULL;
    si.wShowWindow    = SW_SHOWNORMAL;


    // Must contain at least one parameter
    strcpy(szRun, vParams[0].szValue());

    if (iNumParams >= 2)                        // Has working dir
        strcpy(szDir, vParams[1].szValue());        // Get working directory, if blank get the current working dir
    else
        szDir[0] = '\0';

    if (szDir[0] == '\0')
        GetCurrentDirectory(_MAX_PATH, szDir);

    if (iNumParams == 3)                        // Has show flag
        si.wShowWindow = (WORD)vParams[2].nValue();    // Default is SW_SHOWNORMAL


    // If required, init RunAs (dynamically link to retain compatibility with 95)
    if (m_bRunAsSet)
    {
        // Get a handle to the DLL module that contains CreateProcessWithLogonW
        hinstLib = LoadLibrary("advapi32.dll");
        if (hinstLib != NULL)
        {
            lpfnDLLProc = (MyCreateProcessWithLogonW)GetProcAddress(hinstLib, "CreateProcessWithLogonW");
            if (lpfnDLLProc != NULL)
            {
                // Set up wide char version that we need for CreateProcessWithLogon
                // init structure for running programs (wide char version)
                wsi.cb            = sizeof(STARTUPINFOW);
                wsi.lpReserved    = NULL;
                wsi.lpDesktop    = NULL;
                wsi.lpTitle        = NULL;
                wsi.dwFlags        = STARTF_USESHOWWINDOW;
                wsi.cbReserved2    = 0;
                wsi.lpReserved2    = NULL;
                wsi.wShowWindow = si.wShowWindow;                // Default is same as si

                wszRun = Util_ANSItoUNICODE(szRun);                // Get wide char version of the run string
                wszDir = Util_ANSItoUNICODE(szDir);                // Get wide char version of the dir string
            }
            else
            {
                FreeLibrary(hinstLib);
                FatalError(IDS_AUT_E_RUNASFAILED);
                return AUT_ERR;
            }
        }
        else
        {
            FatalError(IDS_AUT_E_RUNASFAILED);
            return AUT_ERR;
        }
    }


    // RunAs or Normal?
    if (lpfnDLLProc == NULL)
        bRes = CreateProcess(NULL, szRun, NULL, NULL, FALSE, 0, NULL, szDir, &si, &pi);
    else
    {
        bRes = lpfnDLLProc( m_wszRunUser, m_wszRunDom, m_wszRunPwd, m_dwRunAsLogonFlags, 0, wszRun, 0, 0, wszDir, &wsi, &pi );
        delete [] wszRun;                        // Free our wide strings
        delete [] wszDir;
    }


    // Check for success
    if (bRes == FALSE)
    {
        if (hinstLib)
            FreeLibrary(hinstLib);

        if (m_bRunErrorsFatal == true)
        {
            FatalError(IDS_AUT_E_RUNPROG, FormatWinError());
            return AUT_ERR;
        }
        else
        {
            SetFuncErrorCode(1);                // Indicate an error (silently)
            vResult = 0;                        // Also set result to 0 (default 1)
            return AUT_OK;                        // Nothing to tidy, so return now
        }
    }


    // Tidy up
    if (hinstLib)
        FreeLibrary(hinstLib);

    CloseHandle(pi.hThread);


    // If this is a RUNWAIT command, track the process
    if (nFunction == 1)                            // RUNWAIT
        m_piRunProcess = pi.hProcess;
    else                                        // RUN
    {
        vResult = (double)pi.dwProcessId;        // Pass the PID back as the result
        CloseHandle(pi.hProcess);
    }

    return AUT_OK;

} // Run()

Alles anzeigen

Professor Bernd

Zitat von AspirinJunkie

Edit: Achso - du wolltest ja den Quellcode zur Run()-Funktion:

Alter Schwede! Wie kommst du an solche Sahnestückchen!?

Zitat von AspirinJunkie

Run() ruft die Windows-API-Funktion >>CreateProcess<< auf.
Dort findet sich folgender wichtiger Hinweis:
Zitat von CreateProcess-Dokumentation

The new process runs in the security context of the calling process.

Zwei Sätze weiter heißt es:

Zitat von CreateProcess-Dokumentation

To run the new process in the security context of the user represented by the impersonation token, use the CreateProcessAsUser or CreateProcessWithLogonW function.

Im Quellcode von Run scheint CreateProcessWithLogonW bei Bedarf genutzt zu werden, damit das aufzurufende Programm in einem anderen Security-Kontext laufen kann.

Code

    // If required, init RunAs (dynamically link to retain compatibility with 95)
    if (m_bRunAsSet)
    {
        // Get a handle to the DLL module that contains CreateProcessWithLogonW
        hinstLib = LoadLibrary("advapi32.dll");
        if (hinstLib != NULL)
        {
            lpfnDLLProc = (MyCreateProcessWithLogonW)GetProcAddress(hinstLib, "CreateProcessWithLogonW");
            if (lpfnDLLProc != NULL)
            {
            ...

Alles anzeigen

So, falls dich der Ehrgeiz packt, da noch eine Info zu geben, halte ich dich nicht auf. Aber ganz ehrlich, diese Mühe musst du dir nicht machen! Das Ganze ist doch viel anstrengender geworden, als ich es ursprünglich dachte und sooo interessant ist das auch wieder nicht.

Also, Leute, ich bedanke mich recht herzlich für eure Informationen! - Jetzt spendier ich euch erstmal ein Bier. Kommt, ab an die Theke!

**alpines**

Zitat von Professor Bernd

Alter Schwede! Wie kommst du an solche Sahnestückchen!?

Google doch einfach mal! Au3 war ja bis zu einer bestimmten Version Open-Source und seitdem hat sich an der Run-Funktion sicherlich nicht viel getan.