Discussion :

[daerlnaxe]

HEllo à tous,

Comme je planche sur une app avec des plugins, je suis arrivé à un point qui me fait gamberger souvent et j'ai l'impression, peut être que je me plante, que le garbage collector amène une faille. Bon ça a peut être déjà été abordé et peut être que j'arrive après la bagarre. Après on peut décharger probablement les dlls mais ça doit avoir un coût je pense de décharger recharger. (Attention je suis sous .net core 3)

Si je prends une application qui utilise des plugins, et bien sur sous réserve que derrière on ne passe pas son temps à aller éplucher les plugins que les gens pondent pour votre app...

Tous les mécanismes de sécurité que je peux pondre pour bloquer des actes malveillants, qui se serviraient par l'ajout de plugins à mon app, me semblent contournables d'après ce que j'ai lu en Anglais sur divers sites.


Alors bien sûr certaines protections qui tourneraient en continue ne sont la plupart du temps pas contournables mais si par exemple je veux me créer un écosystème de fichiers que je vais surveiller, et protéger le temps de faire des calculs dessus, que mes plugins ont un accès lecture, il suffit si je ne m'abuse de créer une tâche qui va boucler, dans un plugin, attendre donc que l'app principale libère l'accès au fichier, et de là je peux les corrompre comme il me chante. Et ce pourquoi je parle du garbage collector c'est qu'en fait mon app principale pourrait appeler un dispose que de toute manière il y a des moyens de contourner le problème via cette tâche de manière à ce que le garbage collector passe et juge qu'il est normal. Alors que je pourrais avoir un meilleur contrôle sans, si je ne m'abuse.

Je sais que ça peut paraître étrange comme réflexion, peut être que je suis même naïf, mais le système de plugin devrait être un peu à mon sens comme un système d'OS avec des droits que l'on pourrait gérer. Or là ça me parait open bar du coup, sachant qu'on peut avoir une appli qui nécessite des privilèges élevés, de fait les plugins qui s'ajoutent à cette appli peuvent amener un énorme lot de problèmes. Là je songeais que du coup on peut même avoir un plugin qui formaterait les hdd et autres saletés :/ . Sachant qu'une de mes apps se lance en service.

J'ai songé à un numéro ID unique, mais ça reste duplicable dans tous les cas ?

Peut être quelque chose existe dont j'ignore l'existence ? Je suis peut être un peu parano, mais ça me turlupine depuis un moment.

[François DORIN]

Après on peut décharger probablement les dlls mais ça doit avoir un coût je pense de décharger recharger. (Attention je suis sous .net core 3)

Impossible en .Net Core. Décharger un assembly ne peut se faire qu'en déchargeant le AppDomain dans lequel il est contenu (et donc TOUS les assemblys du AppDomain). Malheureusement, les applications .Net Core ne supporte qu'un seul et unique AppDomain.

Alors bien sûr certaines protections qui tourneraient en continue ne sont la plupart du temps pas contournables mais si par exemple je veux me créer un écosystème de fichiers que je vais surveiller, et protéger le temps de faire des calculs dessus, que mes plugins ont un accès lecture, il suffit si je ne m'abuse de créer une tâche qui va boucler, dans un plugin, attendre donc que l'app principale libère l'accès au fichier, et de là je peux les corrompre comme il me chante. Et ce pourquoi je parle du garbage collector c'est qu'en fait mon app principale pourrait appeler un dispose que de toute manière il y a des moyens de contourner le problème via cette tâche de manière à ce que le garbage collector passe et juge qu'il est normal. Alors que je pourrais avoir un meilleur contrôle sans, si je ne m'abuse.

J'ai l'impression que la protection du fichier passe par un lock via ton application du fichier, pour empêcher d'autres de le modifier. Dans ce cas, oui, dès libération du verrou, le fichier est de nouveau accessible en écriture.

Je sais que ça peut paraître étrange comme réflexion, peut être que je suis même naïf, mais le système de plugin devrait être un peu à mon sens comme un système d'OS avec des droits que l'on pourrait gérer. Or là ça me parait open bar du coup, sachant qu'on peut avoir une appli qui nécessite des privilèges élevés, de fait les plugins qui s'ajoutent à cette appli peuvent amener un énorme lot de problèmes. Là je songeais que du coup on peut même avoir un plugin qui formaterait les hdd et autres saletés :/ . Sachant qu'une de mes apps se lance en service.

Alors, c'est rare quand je dis ça, mais ici, si tu fais un système avec des droits élevé et qui chargent des plugins, tu devrais songer à utiliser non pas du .Net Core mais du .Net Framework.

Via la création de AppDomain, tu peux controler les permissions. Et tu peux le faire assez finement. Par exemple, pour l'accès au système de fichier, tu peux préciser quels sont les répertoires accessibles, et comment.

[Pol63]

Impossible en .Net Core. Décharger un assembly ne peut se faire qu'en déchargeant le AppDomain dans lequel il est contenu (et donc TOUS les assemblys du AppDomain). Malheureusement, les applications .Net Core ne supporte qu'un seul et unique AppDomain.

J'ai pas encore retrouvé le code, mais j'avais assisté à un MUG (y a quelques mois) où le gars expliquait qu'on pouvait décharger un assembly en .net core
c'est peut etre ca : https://docs.microsoft.com/en-us/dot...blyloadcontext
enfin y avait une surcharge de méthode load avec un booléen pour spécifier qu'on voulait pouvoir décharger après

[François DORIN]

J'ai pas encore retrouvé le code, mais j'avais assisté à un MUG (y a quelques mois) où le gars expliquait qu'on pouvait décharger un assembly en .net core

Si tu retrouves, je suis preneur ! Car à moins d'avoir raté un épisode sur le sujet, c'est intrinsèquement impossible :/ Ou en tout cas, pas de manière forcée : que se passerait-il si on déchargeait un assembly dont un type était encore référencé par exemple ? Les AppDomain, en créant des "barrières" répondaient justement à ce genre de questions.

Je vois plutôt le truc comme étant un moyen de dire que l'assembly ne sera plus utilisé, donc à l'occasion, si tu en as la possibilité, tu peux le décharger. Je vais creuser un peu le sujet en tout cas. Merci.

[daerlnaxe]

Merci énormément pour toutes ces informations ! Je vais prendre le temps de bien lire et digérer tout ça !

J'étais sur .net Framework et j'ai changé pour .net Core par rapport à l'actualité, les annonces de MS. En effet je passe par l'ouverture des fichiers par mon application, je sais qu'on peut carrément modifier les droits d'accès, j'imagine qu'en fait je pourrais couper les droits d'accès aux utilisateurs (peut être admin), mais l'idée me refroidit pas mal pour le moment. Donc en effet il suffit qu'à la fin de la boucle je lève ces ouvertures pour qu'immédiatement, avec une boucle lancée derrière ça contourne ce lock. Bref, je vais lire ce que vous m'avez mis sinon je vais parler pour ne rien dire.

Bonne journée à vous deux !

[Pol63]

Je vois plutôt le truc comme étant un moyen de dire que l'assembly ne sera plus utilisé, donc à l'occasion, si tu en as la possibilité, tu peux le décharger. Je vais creuser un peu le sujet en tout cas. Merci.

ca doit être ca, car c'est collectible donc c'est le gc qui le fait

[François DORIN]

ca doit être ca, car c'est collectible donc c'est le gc qui le fait

Bingo : https://docs.microsoft.com/en-us/dot.../unloadability

On précise bien qu'on souhaite le décharger, mais on ne peut pas forcer le déchargement, alors que c'était possible avec les AppDomain. Et impossible de gérer la sécurité de manière fine non plus donc...