7zip bestimmte Ordnernamen brauchen Admin Privilegien bei selbstentpackenden Archiven

Zitronella

Ich frage mal hier, da ich meine, dass hier viele 7zip verwenden.

Ich habe einen Ordner mit dem Namen unins, packe dort lediglich ein leeres Textdokument rein und mache mit 7zip ein selbst-entpackendes Archiv also unins.exe draus. Es braucht keine Admin Privilegien bei Doppelklick zum entpacken und genau so soll es sein. Es wird ja nur der Ordner entpackt.

Nun ändere ich den Ordnernamen indem ich lediglich ein t dranhänge also uninst und mache das gleiche, also uninst.exe und es braucht Admin Privilegien zum entpacken.

Kann mir das jemand erklären. Es erscheint mir überhaupt nicht logisch, dass das Verhalten am Ordnernamen fest gemacht wird. Und wenn doch, wo ist das hinterlegt und wo kann man das ggf. ändern?

.DeJaVu

Passiert das auch bei winrar? Wie sieht das aus, wenn du andersnamige Ordner als uninst.exe packst?

Mithrandir

An 7zip allein liegt es wohl nicht. Nimmt man eine Kopie einer anderen Exe und benennt diese in uninst.exe um, wird das "Admin.Schild" auch direkt sichtbar.

2002Andreas

Evtl. erzähle ich jetzt Unsinn, dann sorry dafür.

Aber uninst. klingt wie die Abkürzung von uninstall...ieren

Kann es evtl. daran liegen

.DeJaVu

Die Liste mitsamt Doku

https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/hh127439(v%3Dvs.85)

Liste hier

Code

CONTROL.EXE;
DELDRV.EXE;
DESINSTALADOR.EXE;
DESINSTALAR.EXE;
DFSVC.EXE;
EAUNINSTALL.EXE;
GUESTMODEMSG.EXE;
HPZSCR01.EXE;
HPZSCR40.EXE;
INSTALL.EXE;
ISUN0407.EXE;
ISUNINST.EXE;
IUN6002.EXE;
LNKSTUB.EXE;
MSIEXEC.EXE;
MSOOBE.EXE;
SETUP.EXE;
ST5UNST.EXE;
UNINS000.EXE;
UNINS001.EXE;
UNINS002.EXE;
UNINST.EXE;
UNINSTAL.EXE;
UNINSTALL.EXE;
UNINSTALLER.EXE;
UNWISE.EXE;
UNWISE32.EXE;
WERFAULT.EXE;
WLRMDR.EXE;
WUAPP.EXE;

Alles anzeigen

Zitat

Dieser Beitrag wurde vom Autor gelöscht

Da war nichts falsch an deiner Aussage, schade.

Fox2Fox

Es ist sogar so:

Erstelle einen Ordner unins

Mit 7zip erstelle ich ein selbst-entpackendes Archiv - also unins.exe

Wird einfach per Doppelklick entpackt

Erstelle einen neuen Ordner uninst

Mit 7zip erstelle ich ein selbst-entpackendes Archiv - also uninst.exe

Nach Doppelklick wird die Benutzerkontensteuerung aufgerufen

Das wird wohl mit der Bezeichung uninst.exe zusammenhängen.

Vielleicht erkennt Windows, dass es um eine Aktion des Deinstallierens geht. uninstall

Bei Firefox gibt es einen Ordner

C:\Program Files (x86)\Mozilla Firefox\uninstall

Bei keiner anderen Ordnerbezeichnung wird die Benutzerkontensteuerung abgefragt.

Fox2Fox

Zitat von .DeJaVu

Die vollständige Liste mitsamt Doku
https://docs.microsoft.com/en-us/previous…27439(v%3Dvs.85)

Ergibt ein 404

Mithrandir

Resultate bei Archiven wie "install.exe", "uninst001.exe" sehen wie aus?

Zitronella

Danke für die Antworten. Unter dem genannten Registry Pfad Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileAssociation

AddRemoveApps

steht bei mir unter Daten:

Code

CONTROL.EXE;DELDRV.EXE;DESINSTALADOR.EXE;DESINSTALAR.EXE;DFSVC.EXE;EAUNINSTALL.EXE;GUESTMODEMSG.EXE;HPZSCR01.EXE;HPZSCR40.EXE;INSTALL.EXE;ISUN0407.EXE;ISUNINST.EXE;IUN6002.EXE;LNKSTUB.EXE;MSIEXEC.EXE;MSOOBE.EXE;SETUP.EXE;ST5UNST.EXE;UNINS000.EXE;UNINS001.EXE;UNINS002.EXE;UNINST.EXE;UNINSTAL.EXE;UNINSTALL.EXE;UNINSTALLER.EXE;UNWISE.EXE;UNWISE32.EXE;WERFAULT.EXE;WLRMDR.EXE;WUAPP.EXE;

Stimmt, wenn ich eine andere Datei als uninst.exe umbenenne erscheint auch das Schild. Allerdings erscheint das Schild nicht wenn ich sie in wuapp.exe umbenenne, obwohl es auch in der obigen Liste drin ist.

Vielleicht ist ein anderer Registry Pfad verantwortlich. Aber die Richtung scheint zu stimmen

Ich werde die Daten in der Registry natürlich bei mir nicht ändern, ich möchte ja, dass diese Datei auch auf anderen Computern ohne Adminrechte funktioniert. Da hilft wohl nur die Datei selbst umzubenennen.

Fox2Fox

Zitat von Zitronella

Allerdings erscheint das Schild nicht wenn ich sie in wuapp.exe umbenenne, obwohl es auch in der obigen Liste drin ist.

Bei WLRMDR.exe erscheint das Schild auch nicht.

Aber wie entsteht überhaupt diese Vorgehensweise, wie in Beitrag #1 beschrieben.

Du erstellst einen Ordner unins, benennst diesen dann in uninst um. Warum nennst du Ordner genau so?

.DeJaVu

Zitat von Zitronella

ich möchte ja, dass diese Datei auch auf anderen Computern ohne Adminrechte funktioniert.

Das ist von den anderen Rechnern abhängig. Oder du nennst sie einfach anders, ich zB assoziere damit einen Uninstaller. Einzige weitere Quelle

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Diagnostics\Performance\Resolvers

Hat einen ganz anderen Zweck

milupo

Sind denn die Dateien aus der Liste alle im gleichen Ordner? Möglicherweise liegt es nicht am Dateinamen, sondern an den Rechten der Ordner, in denen sich die Dateien befinden.

Zitronella

Fox2Fox ich wolle den Ordner gar nicht so nennen sondern zb. portable-UninstallView.exe und habe versucht heraus zu finden wo das Problem lag und habe es eingegrenzt und kam dadurch darauf, dass der Schritt von uins zu uninst das Problem ist.

milupo : mir ist nicht klar was du genau meinst. Hast du dir meine Grafik angesehen?

Zitronella

Kaum sucht man unter den richtigen Begriffen (7zip hat damit ja nix zu tun) wird man auch fündig

https://www.borncity.com/blog/2018/01/2…ngig-vom-namen/

Zumindest ist das "Problem" bekannt.

milupo

Zitat von Zitronella

mir ist nicht klar was du genau meinst. Hast du dir meine Grafik angesehen?

Dein Screenshot betrifft deine eigene Datei, Ich könnte mir vorstellen, dass Windows nach einer Systemdatei mit diesem Namen sucht (unabhängig vom Ordner deiner angelegten Datei) und diese Systemdatei in einem geschützten Systemordner findet. Der lässt sich dann nur mit Systemrechten öffnen. Das war nur eine Vermutung, weil laut oben einige Dateien aus der Liste von .DejaVu Administratorrrechte brauchten, andere aber nicht. Laut deinem Beitrag #15 scheint es aber nicht so zu sein.

.DeJaVu

Also wenn deine Programme Admin-Rechte brauchen, ist diese Lösung der falsche Weg. Du brauchst einen echten Installer, der diese Rechte explizit anfordert. zB

https://nsis.sourceforge.io/Reference/RequestExecutionLevel

Code

  !define UACMESSAGE1   "Dieses Programm benötigt Admin-Rechte, bitte neu versuchen!"
  !define UACMESSAGE2   "Dieses Programm benötigt Admin-Rechte, Abbruch!"
  !define UACMESSAGE3   "Logon-Dienst nicht aktiv, Abbruch!"
  !define UACMESSAGE4   "Konnte benötigte Rechte nicht erlangen, Fehler:"

  !include "uac.nsh"
  RequestExecutionLevel user ; << Required, you cannot use admin!


!macro Init

uac_tryagain:
  !insertmacro UAC_RunElevated

  ${Switch} $0
  ${Case} 0
    ${IfThen} $1 = 1 ${|} Call Quit ${|} ;we are the outer process, the inner process has done its work, we are done
    ${IfThen} $3 <> 0 ${|} ${Break} ${|} ;we are admin, let the show go on
    ${IfNot} ${Silent}
      ${If} $1 = 3 ;RunAs completed successfully, but with a non-admin user
        MessageBox MB_YESNO|MB_ICONEXCLAMATION|MB_SETFOREGROUND "${UACMESSAGE1}" /SD IDNO IDYES uac_tryagain IDNO 0
      ${EndIf}
    ${EndIf}
    ;fall-through and die
    ${Break}
  ${Case} 1223
    ${IfNot} ${Silent}
      MessageBox MB_ICONSTOP|MB_SETFOREGROUND "${UACMESSAGE2}"
    ${EndIf}
    ${Break}
  ${Case} 1062
    ${IfNot} ${Silent}
      MessageBox MB_ICONSTOP|MB_SETFOREGROUND "${UACMESSAGE3}"
    ${EndIf}
    ${Break}
  ${Default}
    ${IfNot} ${Silent}
      MessageBox MB_ICONSTOP|MB_SETFOREGROUND "${UACMESSAGE4} $0"
    ${EndIf}
    ${Break}
  ${EndSwitch}

!macroend

Alles anzeigen

Gepackt wird mit LZMA (default), das ist unwesentlich mehr als LZMA2. Und da geht noch mehr als ein simples SFX.

Thunderbyte

Dieses Makro hat rein gar nichts mit dem Thema von Zitronella zu tun. Außerdem ist es eines, dass nur für nsis-Installer gültig ist und ohne uac.nsh sowieso nicht funktioniert. Darf man fragen, wozu der Beitrag dient?

Von meiner Seite ein Danke an Zitronella und G. Born. Das ist ein erstaunlicher Effekt. Ich kenne diverse Altlasten, die Windows mit sich herumschleppt. Aber diese kannte ich überhaupt noch nicht. Wieder was gelernt.