Rubbingowe piaskowanie a integracja języka skryptowego

Question

Obecnie pracuję nad tekstowym silnikiem gry w języku Ruby, z aplikacją podzieloną na kod Ruby w/lib i dane YAML w/data, która jest ładowana w razie potrzeby przez grę . Chcę zezwolić, aby pliki danych zawierały podstawowe skrypty, głównie w modelu zdarzeń/obserwatorów. Jednak chcę również, aby użytkownicy mogli generować i udostępniać niestandardowe scenariusze bez obawy o złośliwy kod osadzony w skrypcie.

Uzupełnienie: Mój pierwotny plan był mają treści tworzone przez użytkowników podzielić na dwa rodzaje, „moduły”, które były dane tylko (a więc bezpieczny) i wtyczek, które dodaje dodatkowe funkcje (ale oczywiście nie były bezpieczne). Aby uczynić analogię do gier na tabletach, moduły byłyby jak opublikowane scenariusze przygodowe i treści, a wtyczki byłyby regułami zawierającymi dodatkowe reguły i systemy.

skrypt (składnia z zastrzeżeniem oczywiście zmieniają się w zależności od rozwiązania):

--- 
Location: 
    observers: 
    on_door_open: | 
     monster = spawn_monster(:goblin); 
     monster.add_item(random_item()); 
     monster.hostile = true; 

Z punktu widzenia bezpieczeństwa, byłoby idealnie, gdyby skryptowy był ściśle opt-in, prawdopodobnie za pośrednictwem dołączonego wstawek z trochę DSL, np:

class Frog 
    include Scriptable 

    def jump; ... ; end # this can be called from a script 
    allow_scripting :jump 

    def ribbit; ... ; end # this cannot be called from a script 
end 

szukałem na trzy czterech opcji, ale nie jestem pewien, co jest najlepszym podejściem do podjęcia:

1. Używaj skryptów w języku Ruby, ale w piaskownicy.

   9 Zalety: Bardzo dobrze zna Ruby, nie ma potrzeby stosowania "kleju" kodu lub problemów z łączeniem obiektów między językami.

   Niezbyt zaznajomieni z problemami bezpieczeństwa lub piaskownicą, nie znaleźli żadnych gotowych rozwiązań, które pasują do siebie.

2. Implementacja Umożliwia osadzenie innego języka skryptowego, np. Lua.

   Zalety: Ruby i Lua oparte są na C, więc wiązania powinny być dość proste. Lua jest dość popularnym językiem, więc pomoc dostępna, jeśli napotkasz problemy później. Bezpieczne, ponieważ każda funkcja, której nie wiążę, będzie niedostępna ze skryptów.

   Minusy: Istniejące wiązania Ruby-Lua wydają się być jednokierunkowe, stare i źle utrzymane, lub jedno i drugie. Wygląda na podejrzanego, aby osadzić język skryptowy w innym języku skryptowym.

3. Implementacja niestandardowego języka skryptowego za pomocą interpretera Ruby. Eksperymentowałem z Treetop i nie powinno być zbyt trudno tworzyć prostą gramatykę, która wystarczyłaby dla skryptów.

   Plusy: Nie trzeba osadzać innego języka. Tylko funkcja, którą specjalnie zaimplementowałem, będzie dostępna dla skryptów.

   Minusy: Overkill. Zespół "Nie zbudowano tutaj". Prawdopodobnie czeka nas straszne gniazdo robaków.

4. Wdrażaj pliki danych całkowicie w Ruby, używając języka specyficznego dla domeny.

   Zalety: Prosty i łatwy.

   Żadne dane utworzone przez użytkownika nie są zaufane.

Jestem również otwarty na inne sugestie nieuwzględnione na tej liście, o których być może nie myślałem. Jakie jest najlepsze rozwiązanie do bezpiecznego wdrażania skryptów osadzonych w plikach danych?

Edytuj 2011 年 12 月 23 日: Dodano czwartą opcję z DSL, dodano "dodatek" u góry z dodatkowymi myślami/kontekstem.

Answer 1

Można rozważyć użycie opcji Shikashi gem, która umożliwia tworzenie obszarów izolowanych i definiowanie białej listy dozwolonych wywołań metod dla poszczególnych obiektów.

Answer 2

Należy rozważyć użycie jRuby zamiast Ruby. Java została pierwotnie zaimplementowana do obsługi kodu mobilnego (z powrotem w set-top dni) i ma dobrze przetestowany security model/implementation, który mógł, jak podejrzewam, owinąć wystarczająco jRuby, aby powstrzymać skrypty/klasy użytkowników od spustoszenia z resztą systemu gry . jRuby obsługuje także embedding, co może pomóc oddzielić rdzeń gry od aplikacji użytkownika, chociaż nie wiem, jak bardzo jest on w tym momencie.

I, oczywiście, jRuby to Ruby!