Hallo,

Bezugnehmend auf das hier:
http://stackoverflow.com/questions/2...r-using-delphi

schwebt mir folgendes vor.
Der Admin startet das Admin-Setup-Programm (als Windows-Admin).
Es wird ein Windows-User angelegt, der zwar nicht Admin ist, aber installieren darf, nennen wir ihn mal Setup-User.

Beim nächsten Programm-Update kann der Nutzer ein User-Setup-Programm starten.
Dort rufe ich per RunAs (API-Befehl fällt mir gerade nicht ein) mit dem Setup-User das eigentliche Innosetup-Programm auf.

Ist das Szenario denkbar.
Angeblich macht das ein (Mit)-Bewerber so.


Danke
Heiko

Andere installieren sich einen Updateservice, der die nötigen Rechte hat.

So oder so muß dein Setup/Updater ordentlich geschützt sein, da er ja automatisch alle Rechte besitzt, um die Programmdateien zu ändern.





Alternativ einen Setup-User erstellen, der nicht die vollen Adminrechte bekommt, sondern nur Installrechte auf einen bestimmten Bereich bekommt.
Und wenn das Setup startet nimmt der User dann im UAC nicht den Administrator, sondern jenen Setup-User, gibt dessen Passwort ein und fertig.

Zitat von himitsu:

einen Setup-User erstellen, der nicht die vollen Adminrechte bekommt, sondern nur Installrechte auf einen bestimmten Bereich bekommt.

Wie geht denn so etwas? Wahrscheinlich ist mein Weltbild zu simpel, aber ich dachte es sei so einfach wie "Admin ja/nein". Und nichts dazwischen.

Ich kann dir paar allgemeine Beobachtungen nennen, die allerdings nicht richtig sein müssen.

Unter Windows gibt es standardmäßig den Administrator und Standardnutzer mit eingeschränkten Rechten.

Bin ich Standardnutzer und versuche ein Programm mit RunAs in einem Administrator-Konto zu starten, so gibt es zwei Möglichkeiten:
- das Konto ist nicht Kennwortgeschützt: es steht für RunAs nicht zur Verfügung
- das Konto ist Kennwortgeschützt: es steht für RunAs zur Verfügung

Bin ich ein Administrator und versuche ein Programm mit RunAs in einem Standard-Konto zu starten, so gibt es keine Möglichkeiten:
- das Standard-Konto steht für RunAs nicht zur Verfügung

Ob es da weitere Möglichkeiten gibt, kann ich nicht sagen. So sieht es aber im Explorer mit RunAs aus.


//Edit:

Eine weitere Beobachtung (ist mir gerade eingefallen). Ich weiß nicht mehr ganz welches Programm es war, ich glaube Opera, die hat es in etwa so gemacht: zuerst wird das Programm mit Adminrechten installiert. Dann wird das Programm mit einem Update-Parameter oder ein extra Update-Programm im Aufgabenplaner von Windows eingetragen. Dort kann man die Aufgabe mit einem bestimmten Konto ausführen, also auch mit Adminrechten. Ich kenne mich mit dem Aufgabenplaner auch nicht so besonders aus, auch kann ich mich nicht mehr erinnern wie Opera das machte, beim Start oder zwischendurch, aber gelegentlich meldete das Programm, dass es ein Update fährt. Und da es im Aufgabenplaner mit Adminrechten ausgeführt wurde, klappte auch das Update.

z.B. XP Usermanager
oder eines der vielen Rechte-Tutorials

• Es gibt Gruppen, die besitzen gewisse Privilegien (Rechte etwas tuen zu dürfen)
• Es gibt Benutzer, denen sind eine/mehrere meherere Gruppen zugeordnet, deren Priviledien sie erben
• Man kann einem Adminsitrator oder der Administatorengruppe auch alle Privilegien nehmen und sie dem Gast vermachen
• Und schon kann der Gast alles machen und der Admin darf nix.

http://www.a-m-i.de/tips/winsec/secu_teil2.php
...

Zitat von Der schöne Günther:

Zitat von himitsu:

einen Setup-User erstellen, der nicht die vollen Adminrechte bekommt, sondern nur Installrechte auf einen bestimmten Bereich bekommt.

Wie geht denn so etwas? Wahrscheinlich ist mein Weltbild zu simpel, aber ich dachte es sei so einfach wie "Admin ja/nein". Und nichts dazwischen.

Das geht ziemlich einfach: Nutzer erstellen, in die Gruppe der Benutzer oder gar nur Gäste aufnehmen (eben möglichst wenig allgemeine Rechte) und die NTFS-Zugriffsrechte des gewünschten Verzeichnisses so setzen, dass der gerade erstellte Benutzer dort volle Rechte oder zumindest Schreibrechte hat.

MfG Dalai

Im Grunde muß man ihm garkeine Gruppe zuweisen.

Vielleicht habe ich nicht aufmerksam genug gelesen, aber: "Kein Admin, aber Schreibrechte in einem bestimmten Verzeichnis" deckt doch noch lange nicht "Anwendung installieren" ab, oder? Dazu kommen doch noch Registry-Einträge unter HKLM wie die "Installierten Programme" in der Systemsteuerung und all das.

Zitat von himitsu:

Im Grunde muß man ihm garkeine Gruppe zuweisen.

Äh, da haste recht.

Zitat von Der schöne Günther:

Vielleicht habe ich nicht aufmerksam genug gelesen, aber: "Kein Admin, aber Schreibrechte in einem bestimmten Verzeichnis" deckt doch noch lange nicht "Anwendung installieren" ab, oder? Dazu kommen doch noch Registry-Einträge unter HKLM wie die "Installierten Programme" in der Systemsteuerung und all das.

Es geht laut hoika in erster Linie um Updates einer bestehenden Installation. Aber auch das ist machbar. Die Rechte auf Dateien und Verzeichnisse lassen sich analog auch auf Registry-Zweige setzen, siehe SetACL.

MfG Dalai

Schreib dir einen Dienst, der dieses Update-Gedöns für dich regelt, vom Prüfen über Download bis hin zur Installation.

Für die Kommunikation kannst du einen kleinen REST-Server (oder etwas ähnlich kleines smartes) integrieren, der auf folgende Kommandos hört:

• /check/<AppID>
• /update/<AppID>

Tja und dann macht der Service das, was ich den gefragt habe.

Die Informationen, wo was für die Anwendung zu finden ist, trägt am Besten das Setup der Anwendung selber in die Registry (HKLM) (oder wo auch immer - Hauptsache, dort kann nur der Administrator - der User, der installieren darf - schreiben). Der Dienst schaut dann einfach an dieser Stelle nach.

Da so ein Update idR unbeaufsichtigt laufen kann, braucht man auch keine Anzeige.