[władza] Własny język Opcje

[Jabol]

Piszę ten wątek tutaj ponieważ nie pasuje on chyba na php pro gdyż jego tematyka jest zbyt swawolna, a php to już nie to.

Ostatnio sporo myślałem nad systemem php.pl i doszłem do wniosku, że cały system (a raczej kontrola jądra nad modułami -> bezpieczeństwo) będzie w dużej częsci polegała nie na funkcjonalności jądra, ale na zauwafniu, że nikt z develeperów nie będzie umieszczał tam (w kodzie modułów) koni trojańskich ani nic takiego. Mówie tutaj, że jakiś moduł zamiast proszenia BSP o plik sam go sobie weźmie za pomocą sql-layer (tak to bede nazywał) zdobytej przez funkcje global. Może nie byłoby tak z samym systemem ale np. nieoficjalne wtyczki...

Wtedy z pomocą przyszedł mi matrix 2 (sam nie wiem czy był taki nudny, że miałem czas pomyśleć spokojnie, czy wyciągnąłem wnioski z samego filmu (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) ). Co prawda system (matrix) dał się złamać, ale oglądając go doszłem do pewnych wniosków jak dać jądrze kontrole nad aplikacją. W sumie doszłem do takiego wniosku.
Jeżeli chcemy wiedziec co robi aplikacja (mówie ogólnie, w naszym przypadku moduł), czego używa a czego nie i jeszcze na dodatek to wszystko kontrolować, to aplikacja musi działać o poziom niżej w hierarchi od jądra. Innymi słowy aplikacja nie powinna być wykonywana przez parser języka (w naszym przypadku php), ale przez naszą aplikację. W ten sposób każda czynność, każda linijka kodu mogłaby być sprawdzana pod kontem niebezpieczeństw.
Teraz następny problem. Ale jak to zrobić? Ano jak w temacie trzeba napisać własny język. Myślałem o tym. Nie pisałem jeszcze własnego języka i nie mam w tym doświadczenie, ale wymyśliłem jak mógłby wyglądać taki język naprzykład stworzony w XML'u. Pokarze tutaj jak wyobrażam sobie taki "hello world" dodatkowo ze sprawdzaniem parametru z GET'a.
php:[php:1:adb267e0b1]<?php
if( $_GET['say']==1 ) {
print "Hello World";
}
else {
print "I won't say hello to you";
}
?>[/php:1:adb267e0b1]
Własny język w XML'u:

Kod

<application>

<if>

<warunek>

<equal>

<param source="get" name="say" />

<int>1</int>

</equal>

</warunek>

<then>

<out>

<text>Hello World</text>

</out>

</then>

<else>

<out>

<text>I won't say hello to you</text>

</out>

</else>

</if>

</application>

Nie wiem jak tam z moją angielszczyzną, ale mam nadzieje, że założenie jest zrozumiałe. Teraz w XML'u możemy każdą instrukcję sprawdzić i dopiero potem wykonać. Można by było definiować obiekty, a nawet np. stworzyć jezyk obiektowy za pomocą znaczników typu <math:sqrt><int>9</int></math:sgrt>.
Teraz moja największa obawa. Wydajność... Jak by to działało pod względem szybkości. Przy moich założeniach, że każde rozszeżenie poza standart (core) byłoby includowane specjalnym znacznikiem (jak use w perlu, import w pythonie czy dl w php) pamięc nie byłaby zbytnio obciążona.

Takie coś wcale nie jest trudne do wykonania a daje olbrzymie możliwości, jak całkowia kontrola aplikacji instruckja po instrukcji i np. Jeszcze można np.dodac obsługe userów (napisane w php, jako część języka, a potem sprawdzać czy user ma dostęp do wykonywania określinych instrukcji), BSP (z poziomu języka nie można byłoby mieć dostępu do normalnego systemu plików) i można byłoby zboduwać naprawdę potęrzne środowisko do pisania aplikacji w których ważne jest to, że nie mamy całkowitego zaufania do kodu źródłowego.


Wow, ale tekst wyskrobałem.
Bardzo proszę o komentarze (jeżeli komuś będzie się chcuało to czytać) ponieważ dużo o tym myślałem i jestem ciekwa co Wy o tym sądzicie.
Jeżeli są jakieś niejasności to pytajcie (ja mam wizje i wiem o co mi chodzi ale Wy nie jesteście mną (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) ).

[e-Gandalf]

Mam podobne przemyslenia do autora watku. Koncze wlasnie CMS, nad ktorym troche czasu spedzilem i rowniez natknalem sie na problem "jednej warstwy". W najwiekszym uproszczeniu problem sprowadzilem do jednego przykladu.

1) Zalozmy, ze CMS posiada obsluge kont
2) Zalozmy, ze instalujemy modul X
3) modul X jest blokiem jezyka php poprzez API CMSa zintegrowany z jadrem, ale API jest tutaj "grzecznosciowe", bo modul moze sobie robic co chce.
4) Jak mozna zablokowac mu mozliwosc zmiany hasla dowolnego konta z bazy?

Odrzucilem jednak z miejsca teorie stworzenia jezyka, bowiem nie mam sil mierzyc sie z podobnym zadaniem, zwlaszcza, ze wymagaloby to spowolnienia wykonywania skryptu, a na takie koszty nikt sie nie zgodzi.
Postanowilem przeanalizowac problem bez dzielenia na warstwy...

Mozna rozroznic trzy elementy z ktorych sklada sie problem.

1) Blokada odczytu/zapisu konkretnych zmiennych/walsciwosci oraz uruchamiania konkretnych funkcji/metod
2) Blokada odczytu/zapisu bazy danych zwiazanych z CMSem
3) Blokada odczytu/zapisu plikow na dysku

Jesli pozwolicie zaczne od konca, bo najlatwiej.

Punkt trzeci mozna rozwiklac poprzez blokade konkretnych funkcji (ktorych wcale nie jest tak duzo) lub tez ich podmiane w kodzie. Pierwszy sposob jest ladniejszy, ale nie mam pojecia jak z jego realizacja w php (tzn. wiem, ze istnieja funkcje, ale nie probowalem). Druga metoda jest "brzydsza", ale ma swoje zalety. Mozna np. przyinstalacji modulu zamienic wszystkie wywolania funkcji X na wywolania wlasnej funkcji Y, ktora nie odpali X jesli jednym z argumentow nie bedzie prawidlowy klucz, albo jesli zmienna globalna M nie jest true. I doszlismy do problemu punktu pierwszego. O tym na koncu.

Drugi punkt tez mozna latwo sprowadzic do punktu pierwszego. Mozna wytworzyc piaskownice dla modulu, jesli CMS bedzie mial dwoch uzytkownikow w DB - admina i moduly. Admin dziala sobie z kontami newraligcznymi, takimi jak |accounts|,|privilages|,|session| a przed odpaleniem przelogowuje sie na konto |modul| nie majace do powyzszych uprawnien. Pytanie jak zabezpieczyc sie, zeby modul znowu sie nie przelogowal. Proste. Modul nie mozna znac hasla... i znowu wracamy do punktu wyjscia (czyli punktu pierwszego)

Punkt pierwszy jest najtrudniejszy. Sprowadza sie do pytania, jak stworzyc blok, w ktorym nie bedzie mozna odczytac dowolnych danych bedacych w pamieci.
Z pomoca przyszedl mi blad istniejacy w php (blad/nieblad... moim zdaniem wada). Otorz bedac w strodku metody nie mozemy poznac nazwy obiektu, w ramach ktorego zostala odpalona metoda.
Ta metoda dla mnie dziala, ale ma pare wad. Jak wszystkie opierajace sie na dirty-hackach. Wymaga ciaglego "ukrywania" nazw przed modulem. A to nie wyglada ladnie w kodzie (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Ogolnie doszedlem do wniosku, ze najlepiej poczekac na piatke. Wowczas mozemy zrobic klase CMS, ktorej potomkami beda wszystkie newralgiczne |accounts|,|session|,|access|,|groups| i tak dalej, oraz beda one final. Wowczas wlasciwosci newralgiczne dajemy private, i mamy spokoj. Zaden niegrzeczny modul nie podepnie sie pod nie.... bo mu na to nie pozwalamy (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) A nie majac dancyh (hasel itp.) nie bedzie mogl zalogowac sie do DB, ani podmienic nic innego.

(hmm, slowo wyjasnienia. Jestem tu nowy i zielony, wiec jesli cos niezgodnie z zasadami forum walnalem, to przepraszam *^^*)