Les scripts d'extension doivent-ils être exécutés dans un bac à sable?


11

En particulier, il s'agit d'extensions de jeu écrites en lua (luajit-2.0). Je me demandais si je devais restreindre ce que ces scripts pouvaient faire, et je suis arrivé à la conclusion que je ne devrais probablement pas:

  • Il est difficile de bien faire les choses. Cela semble idiot, mais il y a de fortes chances que mon bac à sable finira de toute façon par fuir.

  • Le seul avantage auquel je pouvais penser serait de donner aux utilisateurs un certain sentiment de sécurité lors de l'exécution de scripts tiers.

  • Les inconvénients seraient que c'est juste incroyablement ennuyeux pour les rédacteurs d'extension. C'est, pour l'instant, moi-même (le contenu du jeu sera principalement scripté).

La raison pour laquelle je pose cette question avant d'avoir réellement quelque chose à présenter, c'est que l'ajout d'un bac à sable au début est facile, mais m'imposerait également les mêmes restrictions ennuyeuses. Cependant, si je continue avec cela puis décide plus tard que j'ai besoin d'un bac à sable après tout, je vais rencontrer des problèmes (je devrais soit réécrire les scripts qui sont déjà là, soit introduire une forme de système de gestion de la confiance qui semble être plus difficile que ça en vaut la peine).


Pour quel genre de jeu? Pour un produit standard, vendu à 100 000 clients, et tous ceux qui aiment peuvent écrire des scripts pour cela? Ou pour un produit vendu 50 fois et vous êtes le seul à proposer des scripts supplémentaires?
Doc Brown

Réponses:


2

Je crois que tant le développement d'un jeu vidéo, que dans tout développement logiciel de dimensions moyennes-grandes, le programmeur tentera toujours de créer un échange de couches ou des options libres pour les fonctionnalités futures.

Lua est un langage qui permet que ces options soient faciles à implémenter pour l'utilisateur final et pour le développeur, mais cela ne signifie pas qu'il est facile de planifier votre espace de travail, avec l'expérience que je peux vous dire aujourd'hui, également une simple multiplication peut fuir, si l'utilisateur final est autorisé à personnaliser son comportement.

Si nous nous concentrons sur ce qu'un jeu de bac à sable a à offrir, nous pouvons léguer pour comprendre que l'utilisation finale peut être une double lame, permettant au jeu de devenir non linéaire, intéressant et amusant , mais en même temps pas un plan facile leurs limites dans la zone de travail.

Du point de vue de la sécurité, cela semble fantastique! un bon environnement de test pour les extensions, devrait être implémenté dans tous les types de logiciels.

En conclusion, je peux dire que même s'il semble que cela ne vaille pas la peine de créer un bac à sable pour votre produit, le développeur ou le groupe de développeurs bénéficiera en fait de plus d'avantages, car comme l'utilisateur final peut facilement configurer votre environnement chez le développeur, il peut également prendre moins de temps pour apporter des modifications à la structure fonctionnelle. Je suis fermement convaincu qu'un jeu sandbox, (comme dans l'évolutivité du logiciel), permet une évolution créative de leurs extensions et une évolution naturelle de ses fonctionnalités.


1
Je pense que vous utilisez le «bac à sable» dans le sens du jeu, mais l'OP l'utilisait dans le sens de la sécurité. Ils semblent à deux concepts assez indépendants.
bdsl

2

C'est difficile de bien faire les choses

Il n'est en fait pas très difficile de créer un bac à sable de base avec une liste blanche de fonctions, puis d'ajouter des implémentations personnalisées de fonctions potentiellement dangereuses. Cette question SO semble être un bon point de départ.

mais les chances sont que mon bac à sable va finir par fuir de toute façon

Je pense qu'il serait suffisant de commencer à fournir une sécurité de base: restreindre l'accès aux fichiers en dehors de certains répertoires spéciaux. De toute façon, les applications 100% sécurisées n'existent pas. Pensez à ce qui peut arriver si quelqu'un écrit une extension malveillante: les utilisateurs vous blâmeront probablement en tant que développeur. Si vous prévoyez de donner à quelqu'un la possibilité d'écrire une extension, vous aurez éventuellement besoin de sécurité. Si c'est seulement vous - c'est bien comme ça.

Le seul avantage auquel je pouvais penser serait de donner aux utilisateurs un certain sentiment de sécurité lors de l'exécution de scripts tiers.

C'est exactement la raison pour laquelle vous devriez faire du sandboxing et ce n'est pas un argument valable contre le sandboxing.

Les inconvénients seraient que c'est juste incroyablement ennuyeux pour les rédacteurs d'extension

J'ai une certaine expérience dans les scripts de jeu et je ne trouve pas gênant de travailler seul dans un environnement en bac à sable. Ce qui m'agace, c'est le manque de fonctionnalités liées au jeu, comme des API spécifiques d'objets dans le jeu ou des implémentations médiocres de ceux-ci.

Cela peut être utile si vous regardez le moteur LOVE comme un bon exemple (si vous ne l'avez pas déjà fait), en particulier un didacticiel sur l'API filesytem .

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.