why (dump) does return so many 'nil s

Started by newdep, April 18, 2007, 04:38:33 AM

Previous topic - Next topic

newdep

Hi Lutz,



doing a (net-eval ... ... "(dump)") does return a real big lists of nils..?

(bigger then a local (dump)) why is that?







and why is this behaviour below happening?



> (net-eval "localhost" 8080 [text](define (one) (println "too many"))[/text])

(lambda () (println "too many"))

> (net-eval "localhost" 8080 [text](dump 'one)[/text])



illegal parameter type in function net-eval : 69

> (net-eval "localhost" 8080 [text](dump one)[/text])



illegal parameter type in function net-eval : 316

>                                                      







Norman.
-- (define? (Cornflakes))

Lutz

#1
doing a (net-eval ... ... "(dump)") does return a real big lists of nils..?
(bigger then a local (dump)) why is that?


'dump' without a parameter will do a big printout of all symbols. 'net-eval' always returns a string on return and evluates is to extract the result expression (it does a 'eval-string' on it). The program sent to 'net-eval' should always return a LISP expression and not do any output. 'net-eval' quotes returned expressions to protect them from evaluation, but that only works for correctly formed expressions not for printed random text.



But if you want to see the original output try the raw mode (see manual):


(net-eval '(("localhost" 4711 "(dump)" true)))

Here your other examples and explanations:


> (net-eval "localhost" 4711 [text](define (one) (println "too many"))[/text])
(lambda () (println "too many"))


because evaluating a (define ...) returns a lambda expression


> (net-eval "localhost" 4711 [text](dump 'one)[/text])
(255184 69 249856 249856 3158000)


gives the correct result for me, cannot reproduce your output


> (net-eval "localhost" 4711 [text](dump one)[/text])
(255184 256 249856 0 249856)
>


gives the correct result for me, cannot reproduce your output.



Lutz

newdep

#2
perhpas I was trying too much in a single newlisp -d session and it got

messedup.. I was quiet impressed by the (define) that could be done,

see my other posting today here...;-)



So actualy Im missing only 1 thing in newlisp when receiving a net-eval

from a client, and that is how to regulate what a remote net-eval may and may

not eval..



That quiet difficult actualy because everything is open, redefining symbols

is not the solution becuase the current problem may not suffer from those.



Actualy I want to protect a newlisp -d session by limiting the way of remote net-eval actions...



There seems to be no way to hide functions from a net-eval... Perhpas a

secret or hidden namespace could help out..? If (context) and (dump) are

the only two functions that could display namespaces then I could rebuild

context and dump to a nil and the namespace functions are hidden.



But all other functions needed in the MAIN context are also needed in the

hidden context, so... Im at a dead end actualy here...



perhaps a hint?
-- (define? (Cornflakes))

newdep

#3
I think i found a solution to protect net-eval from unauthorized eval's..



Actualy its the same as I did with protecting newlisp by replacing functions to a 'nil.



I was thinking of renaming every function in newlisp, everything by using

a rename like ->



> (setq x_define define)

define <804E840>

> (constant 'define 'nil)

nil

> (setq x_println println)

println <8052100>

> (constant 'println 'nil)

nil

> (x_define (what?) (x_println "whot?"))

(lambda () (x_println "whot?"))

> (what?)

whot?

"whot?"

>                    





The question now is... is that possible? is it possible to rename everything

inside newlisp? (i did not test it..just asking seems quicker ;-)







I[edited]



I think this will work...

and if it does I have a Semi-virtual-machine in newlisp where not only predefined functions can be executed via net-eval but also user-define's

can be created with net-eval in a save way, thus without the possibility

of changing the running program structure..
-- (define? (Cornflakes))

Lutz

#4
There is a safer way to do this. Set up  a SSH tunnel for 'net-eval', on your local machine:


ssh -L 1234:mysite.com:9999 norman@mysite.com

you will be asked for the password on the remote mysite.com and a SSH shell for the remote machine opens. Now start the newLISP server on mysite.com:


newlisp -c -d 9999 &

Now on you local machine do:


(net-eval "localhost" 1234 "(+ 3 4)") => 7

All traffic will go encrypted through localhost:1234 via SSH at mysite.com and there to localhost:9999



The mysite.com port 9999 should only be accessible by localhost (mysite.com) itself. If you run inetd on a UNIX machine you can set it up to accept 'net-eval' request only on localhost which then is served by the SSH shell.



Lutz

newdep

#5
Hi Lutz,



Yes an SSH tunnel is usefull when you know who will be connecting.



My idea was to have a protected-newlisp enviroment running where

anyuser can directly have access. (after a registration procedure via

a net-eval)



All procedures (including the registration and login) are build in newlisp

itself.. the newlisp server will run just like "newlisp -c -d 1111".



Anyone that connects to the server needs to register first (this is already working)..

After registration the user can fully use net-eval on the server,

from anywhere in the world...



So why all this trouble? ;-)

Actualy this comes from the idea to be able to execute any newlisp code

on a remote server. Doing this you want to controll what can and cant be used.

So protection of default functions must be done, else the server

can be compromiced.. So the following is the frame-work im building ->





./newlisp -c -d 8080 my-eval-server.lsp





These are the steps that will make sure its all hidden ->



(1) A pre-processor script that replaces all newlisp functions by random-

generated new function names.. like 'println will become random $ABC#&_printnl



(2) the my-eval-server.lsp regulates access from remote net-eval's

    (the my-eval-server.lsp is also converted to the random namings

    using the pre-processor-script.)



(3) Protect/remove all vunarable functions from newlisp (dump exec...etc..)



step 1,2,3 are for protecting local defines and variable access from the outside.



(4) this is the Step im currently hanging... I need to be able to intercept

the incoming net-eval string, to check and pre-process it befor execution...



So if you have an idea on how step 4 could be done it would be finished ;-)



Norman.
-- (define? (Cornflakes))

Lutz

#6
Quote4I need to be able to intercept  the incoming net-eval string, to check and pre-process it befor execution..


'net-eval' commands come in just like a command on the newLISP command line. The 'newlisp -c' is really just a normal command line mode with suppressed prompts (thats what -c stands for). You can try this by doing telnet to the server and entering newLISP expressions. Or by just starting newLISP doing 'newlisp -c' and enter expressions. At the same time '-c' mode also enables the processing of HTTP commands. The -http mode is just a HTTP-only mode without the net-eval/commandline.



When 'net-eval' sends an expression for evaluation is brackets them with [cmd] and [/cmd] each on separate lines. So if you do a:


(net-eval "localhost" 1111 "(+ 3 4)")

what arrives at the server is three lines:


[cmd]
(+ 3 4)
[/cmd]


This way 'net-eval' can process multi-line requests, e.g. bigger function definitions.



To intercept incoming request you could just use 'read-line', to send info back to the client just use 'print/println'. To debug your program just use telnet and entering everything as shown above bracketed with [cmd], [/cmd] to simulate exactly what an incoming 'net-eval' request would do.



You may also consider using newLISP server together with the UNIX inetd utility. The big advantages are the following: For each client connection you will have a new startup/session of newLISP server. At each connection your startup code will load again and you start newLISP in a fresh state without some potential bad situation left by a previous connected client.



Another advantage is that you can handle many connections at the same time. The inetd utility will start a new newlisp instance for each connection. To finish a connection you just let the cient exit.



Lutz

newdep

#7
Yes those options passed my mind too, and the read-line i still like the best,

but I think i realy need to bake my own tcp handler... inetd is handy if you have

root provileges on a machine and spawning on a machine newlisp binary's is also

an option but in my environment every newlisp session must communicate &

share the same environment as any other client-sessions.. So every client has the same environment.



I will rebuilt my tcp broker into a net-eval snatcher, so the user can still use

net-eval, my program is multi session, i dont have to use share or other sharing

devices between the clients..the only way  to maintain the data stream from

the clients is to controll every net-eval all in 1 newlisp session.. If that works the "net-eval-secure-multi-client-server-environment-semi-virtual-machine-sharing-dispatcher" is born in newlisp..
-- (define? (Cornflakes))