World: r3wp

It depends on the data.

The question is, if it should create sandbox for each user, I mean 
letting user to download something, save something, call something, 
parse it, etc. Or do you want to limit console to prevent file operations 
for e.g.?

do join "call " "init 0"

Optimally the sandbox would have to be handled entirely by R3 alone.

Henrik - the only option you have in limiting system resources is 
some CPU cycles for R3 process. Carl refused to add e.g. time/memory 
usage variation ...

Graham, I think this can be intercepted with LOAD. Perhaps you can 
redefine CALL to become harmless, or simply return a restriction 
error.

the secure feature will have to be set so that everything is secured.

this will limit access to external stuff... doesn't call have its 
own secure option?

'call has its own security setting IIRC ...

Pekr, yes, that will be an issue. But I think Carl will eventually 
comply, once he sees that this is a problem.

Max was faster :-)

I wonder if there are generic javascript ajax consoles around we 
can grab...

Henrik - sometimes you have to ask Carl more than few times in order 
for something to be noticed :-)

Pekr, once he sees my poor smoking Linode server brought down by 
R3, he'll notice. :-)

It has to be also settable by command line option, or it does not 
have any sense. Your user will not add it to his script himself ...

true

I wonder - what happens, when user types "demo" and View is supposed 
to be launched? An error?

hmm.. tried this briefly in win32:

>> call "dir"

** Access error: external process failed: "The system cannot find 
the file speci
fied.^M^/"
** Where: call
** Near: call "dir"

What's call's environment?

henrik - we discussed it here with BrianH week or two ago. CALL is 
now more low-level, hence use call "cmd.exe /c dir c:"

Pekr, I see, thanks.

dir isn't a prograam, it's a cmd.exe command.

http://tryruby.sophrinix.com/js/irb.js

Also look at my rants in #1223 - call needs some fixes, or it reqires 
you to press enter, once it finishes, as well as it messess console 
output (prompt), as well as call output can't be caught into series 
...

Pekr, demo is a mezz. Another issue is graphics commands, lowlevel 
View and such. How do we handle that? I'm not sure we want to submit 
graphics via HTTP to the browser.

Also what happens if you forcefeed R3 with events? is that possible?

Henrik - we might have more problem that that. Even with real plugin 
- imagine networking - we have our own networking, we don't use browser's 
one. For the console demo, it should not be probably a problem though 
....

that looks like the JS that loads into the console div

Actually a RT branded Chrome browser would be great .. have R3 embedded 
into it.

Pekr, we can shut down networking too with SECURE, AFAIK.

Graham - what would be the purpose? It would be standalone app (R3 
+ Browser), and your apps would not run anywhere else, no?

Henrik - if you shut down networking, you prevent many cute examples 
and one-liners, as print read http://www.rebol.com

I think that maybe networking is not a problem. I would shut 'call 
though, or some users will try to inspect your system :-)

yes, but how do you then prevent: read http://somewhere.com/16GBiso.iso
?

Linode have some network abuse policies. I think we don't want networking 
at all here. Imagine a spammer taking advantage of this.

could spammer wrap the process to its advantage?

you could probably paste a binary that is decompressed and voila: 
SMTP server.

9. The user needs to be able to control the console. If something 
goes awry, he has to be able to type "reset" to reset the console. 
I'm thinking maybe it's possible to control several R3 processes 
through one R3 mother process or arbiter.

You can prevent READ anything with SECURE.

Can we prevent the creation of ports in case someone provides a low 
level alternative to READ?

Yeah, all file operations, even through ports.

henrik, maybe you can create modules for each session and use do 
within each module... they will be shielded from each other, but 
you'll only need a single rebol process to run all users  :-)

Pekr, it would be Chrome + Rebol ...

Maxim, hmm, yes, but does this not require tasking?

Henrik, there was a guy on EC2 who had his instance exploited thru 
some vulnerability and it started spamming for  a while. And the 
spamcop or something blocked his smtp server :(

the trouble with these vigilante groups is that you're guilty until 
proven innocent.

no whatever calls your R3 decides which module to interact with and 
just calls something inside the module which returns the result of 
a 'DO executed from within the module.

What I am thinking is that your R3 would be talking to cheyenne via 
a tcp port and the communication would include a session number, 
which is mapped within your R3 server to a specific module.  you 
could easily kill modules when some events happen like sessions being 
 inactive too long

Graham, perhaps we should simply log everything typed into the console. 
This would be nice for debugging purposes as well.

so basically, you build a little module in cheyenne which does a 
tcp exchange to your R3 server.  

the R3 server maps the request to a module, returns the molded result.

cheyenne then returns the value in an xml block which your ajax app 
did the request for.


allowing multiple handlers on the cheyenne side (and an equal amount 
of R3 servers) would allow you to support multiple concurrent users, 
but you'd have to map which R3 service is being used within the cheyenne 
module, in order to send your tcp request to a free R3 service.

does any of this make sense?

http://97.107.135.89/projects/rebol/r3shell/


The humble beginnings. Nothing working at all yet. Just some boxes 
and HTML.