Discussion :

[SergioMaster]

Bonjour,

Je stocke mes fichiers de configuration de programme dans ProgramData\<nom programme>\maconfig.ini (.ini pour faire simple)
Quand le répertoire n'est pas créé je crée celui-ci par ForceDirectories
Jusque-là pas de soucis.

C'est ensuite que cela se corse :
Sur mon poste, pas de soucis, si je modifie le fichier de config aucune erreur de levée
Sur certains postes utilisateurs (pas tous ce serait trop facile) impossible de ré-écrire le fichier sans exécuter le programme en mode administrateur

Si j'en crois cette réponse

C: \\ ProgramData, alias FOLDERID_ProgramData, a des paramètres de sécurité restreints. Les utilisateurs standard peuvent y créer des fichiers. Mais ces fichiers sont, par défaut, sécurisés de sorte que seul l'utilisateur qui a créé le fichier peut ultérieurement le modifier.

La solution recommandée consiste pour votre programme d'installation à créer un sous-répertoire de C: \\ ProgramData pour votre stockage partagé. Et ce sous-répertoire doit recevoir une ACL permissive par le programme d'installation. C'est ce qui accorde l'accès souhaité à tous les utilisateurs standard.

La question est donc : comment, je cite, "donner une ACL (Access Control List) permissive" ?

[SergioMaster]

Évidemment je pose une question et en cherchant mieux je trouve ce post de Guillemouze

ce code pourrait donc me permettre de contrer le problème

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
if not FileExists(ininame)  then
 begin
   ForceDirectories(ininame);
   {$IFDEF MSWINDOWS}
   // droit d'accès
       ACLParams := '"'+iniName+'" /grant *S-1-5-32-545:(OI)(CI)F';
       ShellExecute(0, 'open', PChar(ACLPath), PChar(ACLParams), nil, SW_HIDE);
   {$ENDIF}
 end;

Votre avis ?
Qu'en serait-il pour un Mac ?

cela ne va pas être facile à tester surtout à distance !

[oneDev]

Il serait peut être plus simple de placer le fichier de config dans un sous-dossier de l'utilisateur, style %appdata%.

[SergioMaster]

Plusieurs utilisateurs sur le même poste mais même config donc GetHomePath n'est pas possible, contrairement aux fichiers de préférences (taille de fenêtre, position, styles) par utilisateur.

Programdata à l'avantage d'être bien protégé, le hic est dû à ForceDirectories

[ShaiLeTroll]

Avec l'UAC qui mettait les fichiers ini en quarantaine en Vista dans son VirtualStore, les fichiers ini ont été abandonné, reste juste des fichiers cfg pour les paramètres systèmes minimum, le format DFM tout simplement et tout le reste dans une table T_REMOTED_INI[VALUES] permettant de gérer des sections communes, des sections par utilisateur (local ou session CITRIX), des sections par machine (local ou client distant sur le CITRIX)

Cela a grandement simplifié la gestion, même le déploiement ...


Sinon, lors du lancement du programme, si le dossier est manquant, as-tu pensé à une élévation de privilège via l'UAC
Oui, cela va solliciter l'utilisateur mais cela fonctionne normalement

Voir aussi à lancer via un ShellExecute un mini programme qui ferait les taches nécessitant une élévation avec un manifest au maximum, ce qui évite de "contaminer" ton projet principal.


D'ailleurs, je ne comprends pas "ProgramData\<nom programme>\" ... n'est-ce pas au Setup de créer ce dossier lors de l'installation de ton programme et la création du fichier de configuration commune, une seule fois pour toute ?
Ou alors, ton programme est un setup maison ?

[SergioMaster]

@Shailetroll J'ai écrit ini pour faire simple, en réalité c'est plus un XML mais j'aurais pu le nommer cfg ou autre.

Sinon, lors du lancement du programme, si le dossier est manquant, as-tu pensé à une élévation de privilège via l'UAC

Oui, le premier lancement (installation) du programme doit se faire en mode administrateur mais justement c'est là ou le bât blesse du coup

Les utilisateurs standard peuvent y créer des fichiers. Mais ces fichiers sont, par défaut, sécurisés de sorte que seul l'utilisateur qui a créé le fichier peut ultérieurement le modifier.

Et c'est ce que fait forcedirectories qui reprend des droits hérités de ProgramData

Ou alors, ton programme est un setup maison ?

Il n'y a pas de Setup donc oui c'est une sorte de Setup maison. C'est le programme qui, a la première utilisation, crée les infos nécessaires de configuration pour tous (en gros les infos de connexion aux bases de données, au serveur ftp, smtp et autres trucs du même genre, infos en partie chiffrées qui plus est). Toutefois j'ai laissé le droit à l'utilisateur de modifier certains de ces paramètres après installation "normale". Sur les 5 postes tests deux m'ont posé soucis : les deux "partagés" entre utilisateurs, pour un sixième c'est pire mais dû à une installation de windows totalement aberrante Je n'ai pratiquement jamais la main sur les postes au moment de leur installations et je ne parle même pas des chaises (PC) musicales au sein de l'entreprise

Lorsque le programme se termine (et c'est là ou ça plante) les dernières informations sont ré-écrites, plusieurs programmes peuvent utiliser tout ou partie de ce même fichier de configuration.