Sicheres exec in python3

Manuelh87 · Samstag 13. August 2011, 12:16

Hallo!

Ist es möglich, exec halbwegs sicher auszuführen? Ich hab schon ein bisschen gegoogelt das besondere bei mir ist, dass z.b. imports einfach verboten sein können, und auch file i/o usw einfach verboten sein darf. Ich benutz das ganze in picklebuild3 (oder auf github).
Picklebuild ist ein Konfigurationswerkzeug und benutzt wieder python scripts um dort Variablen zu definieren usw. Dafür wäre es praktisch, wenn man Dinge wie das ausführen von anderen programmen, das schreiben von Datei, etc verhinden könnte. Das macht das ganze natürlich nicht bullet-proof, aber es sollte zumindest mal ein Anfang sein. Das Ziel ist natürlich schon das ganze ziemlich sicher zu bekommen.
Man sollte das eher als zusätzliches feature sehen. Am sichersten ist natürlich, jedes configure script sich durchzulesen.

Jetzt hab ich schon einiges gesehen, z.b. das hier sieht auch ganz gut aus http://code.activestate.com/recipes/496 ... safe-eval/ aber ich frag mich, ob das nicht einfacher geht... Ich hab schon ein paar Dinge probiert, aber mein Verständnis für die Art und Weise wie nachgesehen wird ob eine Name eine Objekt in __builtins__ referenziert ist mir nicht ganz klar...

Funktioniert hat z.b. ein neues modul zu schreiben, dort from builtins import * zu machen, und dann z.b. open und compile, exec usw zu überschreiben...
Aber das gefällt mir nicht so besonders. Lieber würde ich sowas wie die __getattribute__ methode überschreiben, für ein modul, und dort den Zugriff regeln.
Reicht das überhaupt aus, oder ist das dann nur eine Pseuydo-Sicherheit. Geschützt werden soll man nur vor Dateien die erstellt werden und ausgeführt werden, bzw. vor sämtlichen import Anweisungen...

Ich hoffe ich habe rübergebracht was mein Problem ist...
Schon mal danke im Voraus!
MFG Manuel

sma · Samstag 13. August 2011, 13:08

Hat sich etwas zwischen exec bzw. eval() für Python 2.x und 3.x geändert? Falls nein, sind beide Funktionen unter Python 3.x immer noch prinzipiell unsicher so wie ihre Varianten unter 2.x.

Der zitierte Code scheint den AST zu prüfen und das ganze abzulehnen, wenn bestimmte AST-Knoten vorkommen oder wenn bestimmte eingebaute Funktionen benutzt werden. Prinzipiell ist so ein Ansatz mit einer Blacklist immer problematisch, denn es könnte in neueren Python-Version gefährliche Konstrukte geben, die so nicht gefunden werden. Daher müsste es IMHO eine "whitelist" sein.

Ohne das genauer geprüft zu haben, würde ich vermuten, dass der zitierte Code nicht merkt, wenn ich mir einen Funktionsaufruf von "__import__" (und wenn ich dies habe, kann ich alles nachladen) per Bytecode zusammenstelle und dann die so erzeugte Funktion ausführe. Ungefähr so:

Code: Alles auswählen

#ich definiere mir eine eigene, total harmlose Funktion
def a():pass
#denn ich brauche ein paar Klassen
codetype = type(a.func_code)
functype = type(a)
#nun baue ein code-Objekt, es hat mindestens 12 parameter, die lasse ich weg, aber aber davon ist der Bytecode
code = codetype(...)
#und davon eine eigene Funktion
func = functype(code, a.func_globals)
#nun kann ich meine Funktion aufrufen
func()

Man beachte, dass, wenn ich eine benutzerdefinierte Funktion im Zugriff habe, das ganze auch als ein Ausdruck benutzt werden kann, der mit eval() funktioniert und kein exec() braucht.

Stefan

Manuelh87 · Samstag 13. August 2011, 18:02

Hi! Danke für die schnelle Antwort.

Du hast vermutlich recht, aber um so Sonderfälle kann man ja sicher anders kümmern. (Denkbar wäre die Zuweisung im AST zu finden, das Functions Objekt zu ersetzten, k.a.)

Eigentlich will ich ja verhinden, das z.b. __import__ überhaupt im ausgeführten code zugänglich ist. Der Code darf wie schon gesagt, ziemlich eingeschränkt sein; Im Prinzip sollen nur einfache Dinge wie For-Schleifen und Funktionen + Zugriff auf ein paar globale Objekte, die ich extra übergebe möglich sein. Wenn __import__ nicht in den globalen und lokalen Variablen verfügbar ist, dann hilft auch kein bytecode um da rann zu kommen (nach meinem Verständnis).. Ich versuch aber schon die ganze Zeit rauszufinden wie das genau funktioniert.

Also wenn in dem code z.b. 'open' steht, wie genau löst python das auf?? Ich dachte es macht sowas wie getattr('open') und getattr checkt dann die locals und die globals und danach __builtins__... aber das ist nur eine ganze naive Vorstellung von mir... Ich versuch grad herauszufinden wies ist, aber die docu hat da bisher nichts hergegeben...

Oder ist schon der Ansatz völlig unbrauchbar? Fürs erste würds mir reichen, wenn imports und open und exec usw. mal nicht 'einfach' möglich sind. Denn um die Spezialfälle kann man sich dann denk ich immer noch kümmern. Wie gesagt, diese Skripts sind relativ leicht lesbar und sollten eigentlich nur wenige Befehle beinhalten, keine komplexen structuren usw. wesentlich einfacher als die üblichen configure Skripts, von denen ich mir auch noch kaum eins angesehen hab und die ein ebenso hohes risiko in sich bergen wie mein configure Skript. Es ist also auch mehr als eine Schutz vor 'dummen Dingen' die der Nutzer des Konfigurationssystem nicht tun soll, da es nicht vorgesehen ist... (Er soll z.b. keine dateien erzeugen, denn das funktioniert hier einfach anders. Wenn er einfach Datein erzeugen will, soll er einfache configure skripts schreiben...)

MFG Manuel

snafu · Samstag 13. August 2011, 18:34

Ich würde mir mindestens zweimal überlegen, ob ich tatsächlich soviel Aufwand für ein bißchen mehr an Komfort betreiben möchte oder ob ich dem Anwender nahelege, einfach ein bißchen umsichtig zu sein bei dem, was er ausführt. Vermutlich ist deine Implementierung am Ende eh nicht 100%ig sicher und bietet noch irgendwelche Schlupflöcher. Wenn überhaupt, dann ist das IMHO eine Sache, die man lieber einer fertigen Bibliothek überlassen sollte, sofern es dafür etwas entsprechend etabliertes gibt.

Manuelh87 · Montag 15. August 2011, 10:18

Ja du hast ja recht... es scheint echt ne riesen Sache zu sein. Hab zwar noch ein paar nette Dinge gefunden (http://pypi.python.org/pypi/RestrictedPython) aber wird wohl nicht so leicht.

Bin auch nochmal in mich gegangen und hab mir überlegt, was ich eigentlich bezwecken will... ich mein sicher, es ist schlecht, dem user vorzugaukeln es wäre sicher wenn es das dann nicht ist. Aber ein ganz andrer Aspekt spielt fast eine größere Rolle: Eigentlich will ich in erster Linie dafür sorgen, dass keine Dateien geschrieben werden, da dass nicht zu meiner Anwendung passt... Also es soll nicht möglich sein, da sich das Script teilweise nicht so verhält, wie man es erwarten würde. Aber da will ich keinen riesigen Aufwand reinstecken...

Das andere ist natürlich, dass es nett wäre, das Ding halbwegs sicher zu machen. Aber da bin ich von den ursprünglichen Ideen eher abgekommen, obwohl ich immer noch denke, dass in einer so extrem restriktiven Umgebung, wie ich sie bieten würde, es doch möglich sein müsste, das hinzubekommen... aber ihr habt schon recht, man denkt da an vieles nicht, und grad in Python ist es wohl relativ leicht, von einem Objekt ganz schnell irgendwo hinzukommen, wo man Schadcode einschleußen kann... Leider fehlt mir auch das nötige wissen über die Interna von Python und Python Bytecode um das richtig abschätzen zu können...

Dann bin ich über das hier gestolpert und fand ein paar Ideen ganz nett... Was meint ihr was da am leichtesten Umzusetzten wäre?
Ich würde das als eine Art zusätzliches add-on ansetzten, wo man halt z.b. jython auch installiert haben muss, oder der gleichen...

Für Linux hab ich noch etwas nettes gefunden: seccomp. Hab das zuerst mit python das eingebettet in C ist versucht, was gut funktioniert hat, und dann eine reine python Version gemacht... Das wäre ein ansatz den ich halt auf der entsprechenden platform verfügbar machen würde...
Leider hab ich noch nicht rausbekommen, ob es irgendwie möglich ist, den Process ordentlich zu beenden... Ist ein wenig unschön wies in Moment ist...

Was haltet ihr von so einem Ansatz?

cu Manuel

sma · Montag 15. August 2011, 11:11

Ich sage es noch einmal: Wenn du eine Konfigurationssprache haben willst, die sicherlich, dann benutze keine Blacklist, sondern eine Whitelist, d.h. du gehst jeden AST-Knoten deiner Sprache durch und prüfst, ob du ihn erlauben willst oder nicht. Tatsächlich würde ich, wenn die Performance nicht wichtig ist, die AST-Knoten zu Fuß ausführen und nicht auf eval() vertrauen, also quasi einen eigenen Interpreter schreiben. Das ist nicht wirklich schwer, weil man ja schon alle Bestandteile in Python hat. Das lässt sich aber verhindern, dass irgendwelcher nicht gewünschter Bytecode ausgeführt wird.

Stefan

Manuelh87 · Montag 15. August 2011, 16:14

Hi!

Ich sage es noch einmal: Wenn du eine Konfigurationssprache haben willst, die sicherlich, dann benutze keine Blacklist, sondern eine Whitelist

Ja, das hatte ich vor! War ein guter Einwand! Aber in Moment ist mehr das Problem wie man das überhaupt macht von python her und wie ich das am besten abfang; Ob ich da mal ne blacklist oder whitelist verwende, war mir fürs erste Mal wurscht, ich hab da nicht großartig darüber nachgedacht... aber du hast vollkommend recht und ich werd dann auch den Weg im Endeffekt gehen;

Das mit AST ist glaub ich nicht soo leicht zu machen, da ja weiterhin kompliziert verschachtelte Ausdrücke möglich sein sollen, eben nur keine Imports und i/o zugriff... aber das sehe ich mir auch noch an... ein bisschen hab ich mich daran schon versucht, aber da ist noch nicht so viel rausgekommen.

Zusätzlich werd ich aber das mit prctl machen, geht halt nur auf linux (und ich glaub auch nur wenn der kernel damit kompiliert wurde + er eine bestimmte Mindestversion hat) aber das macht ja nix.

Außerdem wirds für das Programm ein flag geben, dass man allen source code sieht, der ausgeführt werden soll (ist vielleicht sinnvol mit einer gui, damit man gleich alles auf einmal bequem durchgehen kann...).

In Moment arbeit ich gerade an dem prctl Teil und werd ihn auch hier posten (als gist oder so) damit interessierte ihn ausprobieren können oder/und mir wertvolle Tips gegeben können was man besser machen könnte. Ich sags gleich, er wirkt etwas unsauber weil ich os.fork stat multiprocessing verwende und syscall direkt aufrufen muss, aber das ist leider nur so möglich und ich denke besser als anders, aber das sehts ihr dann eh...

cu Manuel

jens · Montag 15. August 2011, 18:32

Wenn es nur um Daten geht, die in Dicts, Lists, Tuples stecken (auch verschachtelt), dann ist evtl. mein data_eval aus dem django-dbpreferences Projekt interessant: https://github.com/jedie/django-dbprefe ... ta_eval.py

Oder aber JSON nehmen?

Manuelh87 · Freitag 26. August 2011, 00:20

Hallo!

Es ist schon ein wenig her. Leider hat sich mein Ansatz, für mein Problem als unpraktikabel herausgestellt. So toll dieses Kernel-Jail auch ist, mein Programm ist einfach zu stark abhängig von dem code der ausgeführt wird. Ich hab mir auch den Code von jens angesehen, aber der ist scheinbar nicht für CPython 3.x.x geschrieben. (Jython?).

Auch nett klingt PyPy, da hier ja scheinbar ein virtual-environment freihaus mitgeliefert wird (ich habs nur überflogen..., und es ist schon etwas her).

Tja, vielleicht ist der kernel-jail Ansatz ja mal für wen brauchbar. Hier mein noch nicht endgültiger Ansatz (falls jemand Fragen oder Anregungen hat -> email). Es ist für mich leider nichtmehr von nutzen, also kann ich auch nicht sagen, wann ich den code ein bisschen aufräumen und testen werde. War mein erstes Sphinx dokumentiertes Projekt; Verzeiht also bitte falls ich da irgendetwas ganz böses gemacht habe...

Mein Problem muss ich wohl anders lösen: In Moment arbeit ich an einer vollen emulationen von dem python interpreter (allerdings vorerst ohne Klassen; was vermutlich so bleiben wird). Wie Stefan vollkommend richtig angemerkt hat, ist es anders einfach nicht möglich (soweit ich das beurteilen kann) python irgendwie 'sicher' zu machen. Mann kommt immer irgendwie wieder auf ein Objekt, dass einem Zugriff auf Dinge gibt, die nicht zugreifbar sein sollen. Ich hätte nicht gedacht dass mir zu so einem trastischen Schritt hier in diesem Forum geraten wird, aber in Wirklichkeit hat Stefan recht und es ist wirklich nicht so ein Problem den Interpreter selbst zu schreiben. Mein Design ist leider noch nicht vollständig, nicht zuletzt wegen der stiefmütterlichen Dokumentation von dem ast Modul. Und es wird wohl einige Zeit in Anspruch nehmen.

Ein großes Problem ist, dass ich den . Operator nicht einfach nicht unterstützen will, da mein ursprüngliches Design Objekte zur manipulation vorsieht. Vermutlich (da dies bei mir sowieso wrapper Klassen waren die keine Funktionalität beinhalten) werde ich das Problem mit einer Basisklasse mit whitelist lösen. Falls jemand sehr interessiert ist an dem Thema kann, dann schreib mir einfach eine Mail oder im Forum. Ich will den code nicht verberge, er ist nur noch nicht wirklich vorzeigbar, da ich nochimmer teste wo es zu Problemen mit meinem Design kommen könnte, etc....

Wenn Interesse an soetwas besteht, dann würde ich einfach einen neuen Thread zu dem Thema erstellen, sobald ein akzeptabler Stand vorhanden ist.

cu

jens · Freitag 26. August 2011, 07:54

Manuelh87 hat geschrieben: Ich hab mir auch den Code von jens angesehen, aber der ist scheinbar nicht für CPython 3.x.x geschrieben. (Jython?).

Nein, das ist normales Python v2.x... Für Python 3 müsste man anscheinend ein paar Dinge ändern, hab ich nie getestet. Evtl. mal das 2to3 tool drüber laufen lassen?

Aber was brauchst du denn genau? Wirklich nur statische Daten in listen, tuples, dicts? Oder auch einfache Dinge wie if-Statements?

Reicht da kein JSON?

Manuelh87 · Freitag 26. August 2011, 10:32

Hi!

Oh, tut mir leid, hab übersehen darauf zu antworten...
Ja, JSON und die Basic-Types reicht leider nicht. Es muss möglich sein, Methoden von einem übergebenen Objekt aufzurufen und auch selbst funktionen zu deklarieren, und es soll auch nicht verboten sein, selbst definierte Funktionen aufzurufen...
Auch if und else werden gebraucht, sowie for und höchstwahrscheinlich auch Generatoren (ich weiß nocht nicht genau wie ich das implementieren werde...).

In Moment führt mein Konfiguartionstool einfach eine Art configure - Skript für jedes Modul (C Code) aus, das eine Art Abfrage erstellt. Es geht dabei um statische Werte die sich zur Laufzeit nicht ändern, aber während des compiliern einmal festgelegt werden müssen (diese können auch voneinander abhängig sein, usw..)
Natürlich kann man sagen jeder soll einfach aufpassen und sich die Skripts durchlesen (hab auch daran gedacht einen Befehl einzuführen, der einem alle Codefragmente anzeigt, damit man nicht selber jede Datei durchgehen muss...). Eine denkbare Alternative wäre auch gewesen, mit regex über den code zu gehen und "Gefährliche Konstrukte" zu suchen Beziehungsweise eben Ast zu benutzen und nur nach gefährlichen Dingen zu suchen.

Mein Ziel war es eigentlich nie, den Interpreter neu zu schreiben, aber jetzt wo ich begonnen hab, muss ich sagen, dass einem das ast Modul echt viel Arbeit abnimmt. Es ist zwar trotzdem noch viel Arbeit, aber durchaus möglich.
Ich versuche einen trade-off zwischen "nur für mein Projekt" und "allgemein verwendbar" zu finden. Variablen auflösen und Funktionen ausführen hab ich schon relativ konkrete Vorstellungen und auch Code. Sobald ich einen guten Weg gefunden habe, den . Operator und externe Funktionen gut zu verpacken, werde ich einmal einen Stand erstellen, damit ihr seht, wie ich das angehen will. Es klingt schon irgendwie nach overkill, aber es muss auch nicht sofort anstandslos jeden Code richtig ausführen. Bin schon froh, wenn die wichtigen Dinge klappen. Ich wollt zwar unbedingt python in meinem Konfigurationsskript verwenden (damit man nicht irgendeine halbtolle selbstkomponierte Sprache verwenden muss, die meinem Kopf entspringt aber es scheint nun doch ein wenig in die Richtung zu gehen ;P ) ...
Hier einmal die sprachlichen Elemente, die völlig weggelassen werden:

ClassDef: Keine Klassendefinitionen sind erlaubt
With: Das with Statement ist verboten; Ist nur kompliziert zu implementieren und wird zumindest von mir eigentlich nur für Dateizugriff verwendet, welcher aber verboten ist.
Raise: Exceptions sind ganz allgemein verboten... (Vielleicht ändert sich das aber noch)
TryExcept
TryFinally
Assert
Import
ImportFrom
Lambda: Ist in Moment verboten (da man ja eh mit def eine Funktion definieren kann) aber vielleicht ändere ich das noch.

deets · Freitag 26. August 2011, 12:40

Ich wusste doch, dass mich dieser Thread irgendwie irritiert, und jetzt erinnere ich mich auch wieder warum - ich darf dich mal zitieren:

CMake ist ein build system. Es steuert den gesamten build process und verwendet eine (meiner Meinung nach python wesentlich unterlegene) Sprache die extra dafür gemacht wurde (soweit ich das beurteilen kann) Es hat viele Vorteile, da hast du schon recht, aber es ist soweit ich das verstanden habe nicht möglich (ohne erheblichen aufwand) komplizierte Abfragen einzufügen.

Da warst du noch der Meinung, man braeuchte eine maechtige Sprache fuer dein Build/Konfigurations-Tool. Jetzt mit einem mal doch nicht?

Es ist dir natuerlich voellig freigestellt, zu arbeiten woran du willst. Aber IMHO verzettelst du dich in Nebenkriegsschauplaetzen, die noch nicht mal welche sind. Wenn der Weg das Ziel ist, ist das natuerlich fein.

Ich kann dir aber aus meiner eigenen Erfahrung im Umgang mit Build-Tools sagen: wenn die nicht eine vollstaendige Sprache einbetten irgendwie, mit der ich am Ende *alles* machen kann (und das kann zB auch IO sein und was weiss ich alles), dann kommt irgendwann der Punkt, an dem ich deine goldenen Kaefig zerbrechen werde, weil ich nunmal anders brauche.

Zope2 hat ja zb auch so eine unsaeglich Sandbox fuerr Python-Skripte, und darum ist das Ding auch deutlich Entwickler-feindlicher, als es sein muesste. Und natuerlich gibt es Wege, das zu umgehen - aber die nerven! Und das wird dein Tool dann auch.

Manuelh87 · Freitag 26. August 2011, 15:53

Da warst du noch der Meinung, man braeuchte eine maechtige Sprache fuer dein Build/Konfigurations-Tool. Jetzt mit einem mal doch nicht?

Dieser Meinung bin ich noch immer!

Es ist dir natuerlich voellig freigestellt, zu arbeiten woran du willst. Aber IMHO verzettelst du dich in Nebenkriegsschauplaetzen, die noch nicht mal welche sind. Wenn der Weg das Ziel ist, ist das natuerlich fein.

Da geb ich dir vollkommend recht und es nervt mich auch dass ich schon wieder ein neues Schlachtfeld betrete. Aber ich seh auch einen Nutzen und empfinde dass es die Mühe wert wäre. Auch ohne die genannten Elemente scheint es mir noch immer relativ universell einsetzbar (Außerdem schließ ich es ja nicht für alle Zeit aus, für jetzt ist es mir aber zu kompliziert mich mit jedem dieser Elemente zu beschäftigen, welche für picklebuild kaum eine Rolle spielen).

Ich kann dir aber aus meiner eigenen Erfahrung im Umgang mit Build-Tools sagen: wenn die nicht eine vollstaendige Sprache einbetten irgendwie, mit der ich am Ende *alles* machen kann (und das kann zB auch IO sein und was weiss ich alles), dann kommt irgendwann der Punkt, an dem ich deine goldenen Kaefig zerbrechen werde, weil ich nunmal anders brauche.

Solange man selbst der einzige ist, der den build Prozess anstößt hast du auch absolut recht... Ich finde es immer sehr mühsam, bash Skripts durchzugehen (configure). Man hat 2 Möglichkeiten: Kontrollieren oder Vertrauen. Ich möchte es den Nutzern von Picklebuild möglich machen, sich (relativ) sicher sein zu können, dass der Code nichts böses macht den sie sich runtergeladen haben (also das Konfigurationsskript...).
Im Use-Case von Picklebuild ist es nicht vorgesehen Dateien zu erstellen (aus dem Konfigurationsskript). Nur weil das bei gewissen Build Tools so ist, heißt das nicht, dass es so sein muss. Denkbar wäre include Dateien für bash oder make zu generieren (so wie in Moment für C-Header) aber das ist dann keine Sache die im Konfigurationsskript gemacht wird. (Extensions wären auch noch möglich die einem mehr erlauben könnten aber das würde jetzt zu weit führen und ist ja in Moment nur rein theoretisch)

Zope2 hat ja zb auch so eine unsaeglich Sandbox fuerr Python-Skripte, und darum ist das Ding auch deutlich Entwickler-feindlicher, als es sein muesste. Und natuerlich gibt es Wege, das zu umgehen - aber die nerven! Und das wird dein Tool dann auch.

Also wenn ich das recht verstehe: Eine Lösung eines Problems nervt -> darauß folgt alle möglichen Lösungen müssen auch nerven?

BlackJack · Freitag 26. August 2011, 16:10

@Manuelh87: Falsch verstanden: Die Sandbox in Zope nervt weil die Benutzer mehr machen wollen als erlaubt ist → die Sandbox in einem Build-Tool nervt weil die Benutzer auch dort mehr machen wollen als erlaubt ist.

Wovor willst Du die Leute eigentlich schützen? Letzendlich bauen die mit dem Tool eine Software. Und führen die dann aus. Also müssen sie demjenigen der die Build-Tool-Skripte zum Quelltext gepackt hat, sowieso vertrauen!

deets · Freitag 26. August 2011, 16:17

Manuelh87 hat geschrieben: Man hat 2 Möglichkeiten: Kontrollieren oder Vertrauen. Ich möchte es den Nutzern von Picklebuild möglich machen, sich (relativ) sicher sein zu können, dass der Code nichts böses macht den sie sich runtergeladen haben (also das Konfigurationsskript...).

Das Tool dient dazu, *Quelltexte* zu verarbeiten, die dann auch noch kompiliert werden & auf einem deiner eigenen Rechner - egal ob uC oder PC - ausgefuehrt werden. Und du bist der Meinung, da sollte das *Konfigurationsskript* sicher sein? Mir ist kein Fall von 'configure-is-evil' bekannt (was nicht heisst, das es das nicht gibt), aber Backdoors in diversen damit gebauten Paketen kenne ich eine Menge.

Nochmal: wenn du das machen willst, weil du es machen willst, als intellektuelle Herausforderung - be my guest. Aber nichts, was du in diesem Kontext bisher vorgetragen hast, ergibt in meinen Augen das es ein wuenschenswertes oder gar notwendiges Feature einer Build-Umgebung waere.

Manuelh87 hat geschrieben: Also wenn ich das recht verstehe: Eine Lösung eines Problems nervt -> darauß folgt alle möglichen Lösungen müssen auch nerven?

Am logischen Schliessen solltest du noch mal feilen. Ich habe lediglich ein Beispiel fuer eine aehnliche Situation zitiert, in welcher ein solches "feature" nervt. Das kannst du bedenken, musst das aber natuerlich nicht. Und bei Zope gibt es dafuer sogar noch eine wesentlich staerkere Motivation, da es sich um ein per HTTP zugaengliches, konfigurierbares & programmierbares System handelt, bei dem Sicherheitsaspekte deutlich staerker zu beruecksichtigen sind.

Ich bin aber tatsaechlich der Meinung, dass deine Loesung nerven wird. Weil ich das schon in anderen Kontexten erlebt habe. ZB ant (fuer Java), als pseudo-Sprache in grauenvollem XML. Das ist so beschraenkt gewesen, dass ich irgendwann einen Jython-Interpreter eingehangen habe, um Aufgaben zu erledigen, die eben notwendig waren, aber mittels ant nicht loesbar.

Manuelh87 · Freitag 26. August 2011, 17:44

@BlackJack: Wie kommst du zu deinen Behauptungen? Ich finde nicht, dass diese geplante Sandbox in Picklebuild 'nerven' würde... Picklebuild ist einfach ein anderes Konzept. Wenn du weiterhin ein configure Skript haben willst das Dateien erstellt, kannst du das neben Picklebuild ja verwenden (wie schon erwähnt). Wo ist hier bitte die Einschränkung?
Für die Art von Projekten, für die ich Picklebuild entwickelt habe, ist es nicht notwendig extra noch Dateien zu erstellen. Sollte irgendetwas in die Richtung nötig sein, dann wäre das im Kern drinnen und könnte wieder überwacht werden... Mir ist aber noch kein Szenario untergekommen wo ich das Nötig finden würde. Du hast natürlich recht, dass es andere Möglichkeiten gibt, Schadcode einzuschleußen. Ich hab aber vorallem Mikrokontroller Projekte im Auge welche nicht auf der kompilierenden Plattform ausgeführt werden. Natürlich ist es denkbar, einen Kompilierfehler auszunutzen etc... Aber du wirst mir vielleicht zustimmen, dass dies wesentlich mehr Aufwand darstellt, als einfach ein paar Zeilen Python Code in eine Datei schreiben die k.a. einen Haufen Dateien löschen.
Außerdem ist ein Unterschied, ob du nur die generierten Source Codes von picklebuild durschauen musst, oder auch noch die Konfigureskripts.

@deets: Ich will das ganze ja nicht nur für Picklebuild machen. Ich kann mir vorstellen, dass es auch vielleicht sonst für wen praktisch sein könnte. Ich versuche darauf Rücksicht zu nehmen, aber fürs erste hab ich mal einen Kompromiss aus gerade noch vorstellbar, und für mich nötig gemacht. Klassendefinitionen zuzulassen und dafür zu sorgen dass das dann noch sicher ist kann ich mir derzeit einfach nur schwer vorstellen. Wenn jemand das braucht, dann sollte er vielleicht mal PyPy ansehen, ob das virtual-env was taugt... Falls man aber nur bestimmte Objekte die (~ so wie bei exec globals und locals) von der Anwedung heraus an exec übergeben werden, modifizieren können soll, und dort auch nur bestimmte Funktionen aufrufen darf etc. dann ist mein Ansatz vielleicht brauchbar.
Also für picklebuild konkret, ist es einfach absolut unnötig die verbotenen Dinge zu tun... wenn das jemanden nervt, dann hat er das Konzept nicht verstanden. Das ist so, als regst du dich darüber auf, dass du von einem User-Process nicht in den supervisor Mode wechseln darfst. Das ist per Design nicht erwünscht. Pickelbuild nutzt nunmal das cfg objekt als "Tor nach Außen", bzw. gibt es die Möglichkeit, Extension Befehle hinzuzufügen, die z.b. so etwas ermöglichen... ich seh da nur keinen Anwendungsfall.

Mein Zielpublikum sind eher Einsteiger z.b. ins Programmieren eines Mikrokontrollers. Es soll für diese Leute möglich sein, einfach z.b. meine Source Codes runterzuladen, Picklebuild zu starten (da muss auch noch eine gui her, in Moment geht das nur über cmd-line). Dann steht dort drinnen was welcher Parameter macht, sie wählen z.b. aus wo bei ihnen das Display hängt, kompilieren den Code und es soll schon funktionieren.... Das ist das Ziel. Es soll natürlich auch für Leute wie euch verwendbar sein, die sich sehr gut auskennen, vielleicht die Steuerung über Konsole bevorzugen (Vielleicht in einem make file oder was auch immer). Und auch das schreiben von den Skripts sollte für Neulinge relativ leicht möglich sein. Es gibt nicht viele Befehle und ich werd, sobald ich wieder Zeit habe endlich eine Sphinx Dokumentation erstellen, die ganz einfach erklärt was man machen kann und wie.

Die sichere Umgebung muss einfach jetzt gemacht werden, da sie eben Einschränkungen mit sich bringt. Wenn ich das nicht mach, bevor ich ein "großes Release" mach, dann ärgern sich vielleicht Nutzer, dass ihre Skripts nichtmehr funktionieren. Wenn es von vorn herein z.b. keine Klassendefinitionen gibt, kann man (im Bezug auf Picklebuild) sehr gut damit leben, meine ich...

Zugegeben, es gibt nicht wirklich Nutzer

kann ich auch verstehen, es ist alles noch recht unfertig. Trotzdem hoff ich, dass es vielleicht der eine oder andere Nützlich findet. Mit Picklebuild will ich einfach auch einen Beitrag zur Open Source Gemeinde leisten. Ich habe lange überlegt ob es nicht sinnvoller wäre, bei anderen Projekten mitzuhelfen, die schon benutzt werden. Aber es gab leider nicht ein Projekt hinter dem ich so stehen würde, wie ichs hinter Picklebuild tu, auch wenn ich vielleicht immer der einzige Nutzer davon sein werde ;p
Nehmt es mir also bitte nicht übel wenn ich vielleicht ein bisschen emotional werden wenns um Picklebuild geht... Ich bin allen sehr dankbar für ihre Beiträge...

cu Manuel

jens · Montag 15. Juni 2015, 15:59

...uralt Thread rauskram...

jens hat geschrieben:Wenn es nur um Daten geht, die in Dicts, Lists, Tuples stecken (auch verschachtelt), dann ist evtl. mein data_eval aus dem django-dbpreferences Projekt interessant: https://github.com/jedie/django-dbprefe ... ta_eval.py

Oder aber JSON nehmen?

"Data eval" hatte vor Jahren einzug in django-dbpreferences erhalten. Letzte "alte" version hier: https://github.com/jedie/django-dbprefe ... ta_eval.py

Funktioniert allerdings nicht mehr mit Python 3, weil das compiler Modul weggefallen ist, siehe: https://docs.python.org/2/library/compiler.html

Also hab ich mir eine erweiterte Variante von ast.literal_eval() gebaut: https://github.com/jedie/django-dbprefe ... ta_eval.py

Aber wer viel mehr haben möchte, ist bei https://github.com/newville/asteval/ besser aufgehoben...