love-master project (jail, ...)

[TsT]

EDIT: The project evolved, see the reply below : http://love2d.org/forum/viewtopic.php?p=7219#p7219

You make your our game with love and you have a load() function longer than 2 pages ?
Then love-master is for you !

love-master provide a interface to "replace" the default love callbacks.

Before:

Code: Select all

function load()
  do a 1st thing
  do a 2nd thing
  do a 3rd thing
end

After:

Code: Select all

love.filesystem.require("love-master.lua")
master.autoinstall()

love.load:add("1st_thing", function()
   do a 1st thing
end)

love.load:add("2nd_thing", function()
   do a 2nd thing
end)

love.load:add("3rd_thing", function()
   do a 3rd thing
end)

function load()
   love.load:eval()
end

But love-master provide a simple depends manager.
with a list of constraints, a string : prefix+name
prefix can be :
">" = after
"<" = before

You can have :

Code: Select all

love.filesystem.require("love-master.lua")
master.autoinstall()

love.load:add("3rd_thing", function()
   do a 3rd thing
end)

love.load:add("1st_thing", function()
   do a 1st thing
end, {"<3rd_thing"})

love.load:add("2nd_thing", function()
   do a 2nd thing
end, {">1st_thing","<3rd_thing"})

function load()
   love.load:eval()
end

love-master is also usefull to summarise the complete content of the love's load() callback...

In my own game projet I got something like :

Code: Select all

dump of load :
ORDER NAME                   CONSTRAINTS
    1 show_client_version    []
    2 set_screen_var         [--nodep]
    3 set_title              [>set_screen_var]
    4 memorystart            [--nodep]
    5 memory_stat_1          [>memorystart]
    6 logsystem              []
    7 memory_stat_2          []
    8 load:lua50compat       [--nodep]
    9 load:libargs           [--nodep]
   10 load:pointer           [--nodep]
   11 load:path              [>load:libargs]
   12 bugdetect              [>load:path,--path-is-optionnal]
   13 load:encode            [--nodep]
   14 load:dump              [--nodep]
   15 load:loadsave          [>load:encode,>load:path]
   16 loadsave_part          []
   17 init_config_var        []
   18 set_config_defauts     []
   19 j2h.conf               []
   20 restore_settings       []
   21 save_settings          []
   22 memory_stat_3          []
   23 set_default_font       []
   24 load:love.const        []
   25 load:metatablesort     []
   26 load:layers            []
   27 load:draw              []
   28 load:xmlrpc/workaround []
   29 load:xmlrpc-client     []
   30 load:tree              []
   31 load:box               []
   32 load:stack             []
   33 load:draw2             []
   34 load:drawitem          []
   35 load:input             []
   36 load:ail_init          []
   37 load:calcul            []
   38 memory_stat_4          []
   39 load:colors            []
   40 constants_definition   []
   41 images                 []
   42 load:camera            []
   43 camera_init            [>load:camera]
   44 load:boxloader         []
   45 items_init             []
   46 debug:dump_items       []
dump of update :
ORDER NAME         CONSTRAINTS
    1 patch:update [--autopatched]
dump of draw :
ORDER NAME       CONSTRAINTS
    1 patch:draw [--autopatched]
dump of keypressed :
ORDER NAME             CONSTRAINTS
    1 patch:keypressed [--autopatched]
dump of keyreleased :
ORDER NAME              CONSTRAINTS
    1 patch:keyreleased [--autopatched]
dump of mousepressed :
ORDER NAME               CONSTRAINTS
    1 patch:mousepressed [--autopatched]
dump of mousereleased :
ORDER NAME                CONSTRAINTS
    1 patch:mousereleased [--autopatched]
dump of joystickpressed : empty.
dump of joystickreleased : empty.

I will release the lib soon (maybe tomorrow, I started to wrote the lib this evening...).

To be continue...
Good night

[appleide]

Since I haven't used it yet, what are the advantages of using this vs the normal way of doing things? I'm assuming I might be able to reduce code lines... Can I see actual example source codes using it so I can better compare?

[CR4SH3D]

i think the main thing is so you dont end up with pages in the single load() or update() callbacks and can easily execute them again for instance to restart the game

would make going through the code easier too

[osgeld]

or you could use tables ...

[TsT]

I will release the source code (almost) soon...
as usual, When it run correclty I'm trying to improve it, and finally change almost everything.
Actually it's not running really correctly... (it's run but without managing dependances, and this feature is maybe the best advantage).

Regards,

[TsT]

Finally the lib change and become a must more larger project.

I will try to explain my project, their features and their possible uses.

Summary

Have a secure love environnement to run any .love without fear.

Features

- disable dangerous packages/functions (io, os, debug, ...)
- limit the allow package loadable with lua require()
- limit the view of existing files/directory (see my special hack for LoveUI)
- allow to have a global savedir and by-project savedir
- memory watching with carbagecollector (I think it is not really possible to limit it ?)
- limit file size (can not able to make a disk full)
- filter the socket use (alllow or deny network connection like a small firewall ...)
- restrict the use of file according to the function use to load then
-- for exemple : allow to load only *.mp3 *.ogg by the love newMusic function
- find a way to forbit the overwriting of the love callback
- forbid the use of hided file or file containing special characters
- finally always keep control over the running game!

EDIT: others possible features :
- manage the user preferences : fullscreen/windowed, resolution, alllow/deny to grab the mouse/keyboard
- intercept the error handle, when a error occured in the game, fall back to the jail gui to show them and choose what doing (do not got a LBSD)

Possible other use

you can put the whole content of your project to a directory.
with only my love-master (named main.lua) at the root of the .love file.
My love-master are already able to detect if there is only one directory contaning main.lua to detect what directory will be use for chrooting.


And you have something like :
Before :

Code: Select all

main.lua -- your game
... -- every other file or directory

After :

Code: Select all

main.lua  -- my launcher
yourproject/main.lua -- your game
yourproject/... -- every other file or directory 

Already done :
- the callback part (like described in the first post) is able to manage the love callback and is able to automatically patch the existing callback
- the jail part, currently safely backup and intercept almost every love function that is touch to the filesystem
- the project directory detection, able to detecte all directories that is contain a main.lua file
if there are more than one, stop

To do :
- implement the dependences resvoler to execute in the good order every part of the love callback
- finish to manage the rest of the love function that is require filesystem
- lot of other things ...


My personnal other advantages :
- Have a secure lauchner : that asks me what projet I want to load (with file/directory browsing and selector), after that launch the selected main.lua
- I can run my game project in unsecure environnement into the game directory
or running the secure way. In the secure way I always got the same current directory, so the current savedir (in ~/.love/GAME) will be always the same!
- I currently using 2 time the love-master lib, the first time in the launcher to manage the callback quickly, and patch them after the game (the other main.lua) was loaded.
and the 2nd time in my game to manage the love callbacks, particulary the load one (because I have a very large segment of code, not cleared at all).

Best Regards,

[TsT]

Now I can show a first version of my little crazy project.

The demo shown are the official one, with one personnal demo added into.

Try the demo without the jail :

demo-withoutjail.love

Official demo, with my 0999 (see at the end), without the jail project alpha.

(38.49 KiB) Downloaded 182 times

In the zip file :

Code: Select all

main.lua -- the main.lua of the official demo
e0001.lua
e0002.lua
[...]
e0999.lua -- my personnal demo
[...]

You will see the "0999 jail attack!".
When you run it, the counter grow to 7 and stop because he take the control.
You can see all the callbacks value are equal (except the "draw" and "keypressed").
I have exclude from attack the "draw" and "keypressed" callback to allow to print something and get back to the demo menu.
But this "jail attack" should also do bad things with the "io" or "os" functions like removing all the files from your hard drive ?
But don't be affraid my demo are not dangerous at all

Now try the jailed one :

demo-withjail.love

Official demo, with my 0999 (see at the end), WITH the jail project alpha.

(42.92 KiB) Downloaded 183 times

In the zip file :

Code: Select all

main.lua        -- is a one line file to load the jail.lua
jail.lua        -- the jail project
love-master.lua -- used by jail.lua
stack.lua       -- used by love-master
demo/main.lua   -- the main.lua of the official demo
demo/e0001.lua
demo/e0002.lua
demo/[...]
demo/e0999.lua  -- my personnal demo
demo/[...]

Run it, you can at every moment press F1 to make a break on the game, and fallback to the jail environnement.
The jail environnement (like my demo) will print the callbacks values to show you the difference.

Try my "0999 jail attack!", you will see the counter growing a lot, because he continully try to take the control and the jail restore their callbacks all the time.

You can check every other demo, they should run correctly.

As you can see the demo "0103 Line Iterators" show the main.lua in demo, not the main.lua that is launched because the jail environnement catch the filesystem calls.

Of course the jail functions and variables are not changeable by the game part.


Let me know your comments.

Best Regards,