Le forum (ô combien francophone) des utilisateurs de Powerbuilder.
Bonjour à tous,
nous développons une application en PB 12.5.1 build 4015.
Cette application nous permet d'installer une autre application.
Dans le cadre de cette mise à jour, il y a notamment :
- mise à jour de la variable d'environnement Path
- création de raccourcis pour l'exécutable dans Démarrer\Programmes et sur le bureau de l'utilisateur
Sur Windows XP SP3, pas de soucis, sur Windows 7 32 bits, ça ne fonctionne pas.
Pour la variable Path, on utilise la commande RegistrySet. Pour les raccourcis d'autres fonctions API.
Sur Windows 7, il y a le fameux mode de lancement "en tant qu'administrateur". J'ai l'impression que c'est lié à une histoire de droits.
Quelqu'un a-t-il une idée ?
Razorback
Hors ligne
Win7 (et Vista avant lui) sont extrêmement pointilleux au niveau des droits d'accès.
Entre autres, une appli avec des droits standards ne peut plus écrire dans "c:\" ou "program files" (après la phase d'installation), et un certain nombre de clés de registre sont inaccessible à l'utilisateur standard.
Puisque l'appli est un installateur, il semblerait normal qu'elle s'exécute avec des privilèges élévés. C'est assez facile à obtenir automatiquement en compilant l'appli et en sélectionnant dans l'onglet "Security" la génération d'un manifeste "embedded" et en choisissant un niveau d'exécution "Require administrator". Cela provoquera probablement l'affichage d'un message de confirmation au lancement sur Win7.
Quelques pistes pour étayer mes dires (je rame là-dessus depuis plusieurs semaines ;)
-About Windows Resource Protection
-UAC Architecture
-New UAC Technologies for Windows Vista
-User Account Control Step-by-Step Guide
Hors ligne
Merci beaucoup, je vais lire ces documentations et faire des essais. Je vous tiens au courant.
P.S. : j'aime bien cette citation de Leone.
Hors ligne
En fait, si j'applique cette modification, ça ne fonctionne pas car j'ai oublié de mentionner quelque chose.
Cet utilitaire peut-être lancé en mode "installation" et en mode "mise à jour" mais surtout, il est lancé par un autre exécutable via la commande native PowerBuilder "Run".
J'imagine que cette commande est trop basique pour gérer les niveaux d'habilitation demandés par Windows.
De ce fait, le lancement ne lance rien, l'application n'est pas lancée. Si je baisse le niveau d'exécution, ça fonctionne à nouveau (mais les modifications évoquées dans mon mail précédent ne sont plus opérées).
Du coup, il faudrait peut-être que je passe par une autre commande que Run pour lancer l'exécutable.
Une idée ?
Hors ligne
A tout hasard : shellexecute ?
Hors ligne
Je n'ai pas encore eu le temps de tester.
Je posterai mes commentaires dès que j'aurai pu le faire.
Hors ligne
Je n'avais pas remarqué que ce fil avait bougé.
En fait un process hérite des droits de son parent, càd que si une application tourne avec des droits admin (p.ex si démarrée avec "run as administrator") les processus qui seront démarrés par elle auront aussi des droits d'admin.
Est-ce que l'application tourne avec des droits suffisants ?
Par ailleurs je ne suis pas sûr de comprendre "le lancement ne lance rien, l'application n'est pas lancée." : tu veux dire que le run ne fait rien ? ou est-ce que ce qui est censé être démarré quitte tout de suite ?
Un outil fort utile que je recommande pour étudier les process qui tournent et contrôler les lignes de commande et les droits : Process Hacker (comme Process Explorer mais en mieux).
Egalement : "Si je baisse le niveau d'exécution, ça fonctionne à nouveau" : tu parles de quel niveau ? De l'UAC ? Ou d'un démarrage en utilisateur simple ?
Il faut savoir qu'avec Win7 même si un utilisateur est membre d'un groupe admin, une application n'aura pas forcément les droits d'admin si l'utilisateur ne le demande pas explicitement. J'imagine que c'est pour palier un certain nombre de failles de sécurité potentielles pour les users qui font tout avec le profil "root"...
Peut-être que l'outil AccessChk de SysInternals (maintenant chez Microsoft Technet) pourra t'aider à déterminer les droits nécessaires. Il peut lister les autorisations positionnées sur un fichier, une clé de registre et un certain nombre d'autres objets.
Par exemple, la commande affiche ceci pour la clé "Run"
accesschk.exe -k HKLM\Software\Microsoft\Windows\CurrentVersion\Run\*
RW BUILTIN\Users
RW BUILTIN\Administrators
RW NT AUTHORITY\SYSTEM[/quote a écrit:
Il y a plein d'autres possibilités, on peut aussi tout énumérer :
accesschk.exe -l -k HKLM\Software\Microsoft\Windows\CurrentVersion\Run\* a écrit:
DESCRIPTOR FLAGS:
[SE_DACL_PRESENT]
[SE_DACL_PROTECTED]
OWNER: BUILTIN\Administrators
[0] ACCESS_ALLOWED_ACE_TYPE: BUILTIN\Users
[CONTAINER_INHERIT_ACE]
[INHERITED_ACE]
KEY_QUERY_VALUE
KEY_CREATE_SUB_KEY
KEY_ENUMERATE_SUB_KEYS
KEY_NOTIFY
KEY_SET_VALUE
READ_CONTROL
DELETE
[1] ACCESS_ALLOWED_ACE_TYPE: BUILTIN\Users
[CONTAINER_INHERIT_ACE]
[INHERIT_ONLY_ACE]
[INHERITED_ACE]
GENERIC_READ
[2] ACCESS_ALLOWED_ACE_TYPE: BUILTIN\Administrators
[INHERITED_ACE]
KEY_ALL_ACCESS
[3] ACCESS_ALLOWED_ACE_TYPE: BUILTIN\Administrators
[CONTAINER_INHERIT_ACE]
[INHERIT_ONLY_ACE]
[INHERITED_ACE]
READ_CONTROL
WRITE_DAC
GENERIC_ALL
[4] ACCESS_ALLOWED_ACE_TYPE: NT AUTHORITY\SYSTEM
[INHERITED_ACE]
KEY_ALL_ACCESS
[5] ACCESS_ALLOWED_ACE_TYPE: NT AUTHORITY\SYSTEM
[CONTAINER_INHERIT_ACE]
[INHERIT_ONLY_ACE]
[INHERITED_ACE]
GENERIC_ALL
[6] ACCESS_ALLOWED_ACE_TYPE: CREATOR OWNER
[CONTAINER_INHERIT_ACE]
[INHERIT_ONLY_ACE]
[INHERITED_ACE]
GENERIC_ALL
Dernière modification par seki (09-10-2012 16:48:00)
Hors ligne