Commander.c adds Shell access for Rebol
[1/16] from: fsievert:uos at: 20-Mar-2001 18:49
Hi!
Until RT adds a launch support for /Core and /View you can try my
commander.c program.
It starts the rebol-Interpreter and adds a (very simple) 'call function to
it. You can now type
call "kedit commander.c"
to open kedit with the source-code ;)
How it works:
commander startes REBOL faking a console stream to it. It reads REBOLs
output to find character 0 (ZERO)s in it. Commands are marked
^@command^@
They are executed (in background).
So DON'T OUTPUT CHARACTER ZERO WHEN YOU USE COMMANDER at the moment.
Planned is to add full support of call like in /command and to replace
system/ports/output by a port which escapes character zero so commander
will be absolute transpartent.
Oh, use at your own risk and read the sourcecode:
http://proton.cl-ki.uni-osnabrueck.de/REBOL/commander.c
CU,
Frank
[2/16] from: gjones05:mail:orion at: 21-Mar-2001 5:00
Hi, Frank,
Thanks for the contribution. My C skills have grown very rusty (in fact,
they've never been polished; the last C utility I wrote was 4 years ago). I
have gcc 2.95.2, the "ming win" distribution for windows. The program won't
compile; seems that I don't have the include file termios.h. Am I missing
something obvious? If I have demonstrated just how clueless I am, don't
spend any real time answering, but if I am missing something obvious and
simple, I would appreciate a quick answer.
Thanks!
--Scott Jones
[3/16] from: fsievert:uos at: 21-Mar-2001 13:21
Hi Scott!
> Thanks for the contribution. My C skills have grown very rusty (in fact,
> they've never been polished; the last C utility I wrote was 4 years ago). I
<<quoted lines omitted: 3>>
> spend any real time answering, but if I am missing something obvious and
> simple, I would appreciate a quick answer.
Unfortunately I am not sure, if it will work with windows, since the
console of rebol is allways a window (I think). Since I don't have a
Windows computer, I can not try it.
(Maybe the option "rebol -w" could help???)
If it is possible to run rebol without opening a window and outputting to
a standard output stream, you can try to remove the #incluce <termios.h>
and all stuff that needs it.
Since I am no windows programmer, I don't know if fork() works with
windows. (This is the reason, why the program will not work with AmigaOS,
too)
Maybe someone else can help?
CU,
Frank
[4/16] from: gjones05:mail:orion at: 21-Mar-2001 6:38
From: "Frank Sievertsen"
> Hi Scott!
>
> > Thanks for the contribution. My C skills have grown very rusty (in
fact,
> > they've never been polished; the last C utility I wrote was 4 years
ago). I
> > have gcc 2.95.2, the "ming win" distribution for windows. The program
won't
> > compile; seems that I don't have the include file termios.h. Am I
missing
> > something obvious? If I have demonstrated just how clueless I am, don't
> > spend any real time answering, but if I am missing something obvious and
<<quoted lines omitted: 12>>
> CU,
> Frank
Thanks, Frank, that answers my question. I have not tried REBOL on an
alternate platform in order to see how it might be different. Thanks!
--Scott Jones
[5/16] from: kracik:mbox:dkm:cz at: 21-Mar-2001 14:46
Hi,
No, UNIX functions like fork() don't work in Windows.
Commander.c won't even compile in Windows, because it uses UNIX
specific include files. Also, REBOL's graphical console in Windows
can't be redirected. Perhaps there could be another way to communicate
than Null characters in stdout. Someone on this list posted a solution
where REBOL writes the command to a file, and a simple program checks
if the file exists, executes and then deletes it.
I will try to write a solution where REBOL and "Commander" communicate
with a TCP socket, and stdout is returned to REBOL. It would work both
in Windows and UNIX.
--
Michal Kracik
GS Jones wrote:
[6/16] from: fsievert:uos at: 21-Mar-2001 15:25
> I will try to write a solution where REBOL and "Commander" communicate
> with a TCP socket, and stdout is returned to REBOL. It would work both
> in Windows and UNIX.
Cool, using sockets would be a more transparent solution. I didn't use
them because I wanted a solution that can not be attacked over the net.
But for non-secure enviroments this would be a good and more
portable solution.
CU,
Frank
[7/16] from: kracik:mbox:dkm:cz at: 21-Mar-2001 16:26
Hi Frank,
I think that network security is not a problem here. If I remember
correctly, with C socket library it's possible to listen only on
a specific interface. So if I listen only on local loopback interface
127.0.0.1 and some port, noone from the network can attack my program.
But perhaps there is another problem that I overlooked?
Regards,
Michal Kracik
Frank Sievertsen wrote:
[8/16] from: deryk:iitowns at: 21-Mar-2001 23:41
Michal Kracik wrote:
> Hi Frank,
>
> I think that network security is not a problem here. If I remember
> correctly, with C socket library it's possible to listen only on
> a specific interface. So if I listen only on local loopback interface
> 127.0.0.1 and some port, noone from the network can attack my program.
> But perhaps there is another problem that I overlooked?
Sure, 127.* can be rerouted and an attack can take place that way. :)
Deryk
-- Binary/unsupported file stripped by Listar --
-- Type: application/x-pkcs7-signature
-- File: smime.p7s
-- Desc: S/MIME Cryptographic Signature
[9/16] from: fsievert:uos at: 21-Mar-2001 16:46
> I think that network security is not a problem here. If I remember
> correctly, with C socket library it's possible to listen only on
> a specific interface. So if I listen only on local loopback interface
> 127.0.0.1 and some port, noone from the network can attack my program.
> But perhaps there is another problem that I overlooked?
Maybe an other user (on the same machine) could try to attack. I think it
would be good to have both solutions.
And even better: RT would give us 'call for /core and /view.
CU,
Frank
[10/16] from: ryanc:iesco-dms at: 21-Mar-2001 9:27
How making it basically a telnet daemon, but with the rigorous security
features you mention?
--Ryan
Michal Kracik wrote:
> Hi Frank,
> I think that network security is not a problem here. If I remember
<<quoted lines omitted: 26>>
> [rebol-request--rebol--com] with "unsubscribe" in the
> subject, without the quotes.
--
Ryan Cole
Programmer Analyst
www.iesco-dms.com
707-468-5400
I am enough of an artist to draw freely upon my imagination.
Imagination is more important than knowledge. Knowledge is
limited. Imagination encircles the world.
-Einstein
[11/16] from: dlhawley:home at: 21-Mar-2001 9:44
Previously, you (Frank Sievertsen) wrote:
> On Wed, 21 Mar 2001, Colin Brizell wrote:
>
> > I have a small question, how can I capture the output in REBOL of
> > the command I call?
There's a script called little-bell.r on rebol.com which might do this.
--
David L. Hawley D.L. Hawley and Associates 1.503.274.2242
Software Engineer [David--L--Hawley--computer--org]
[12/16] from: c:brizell:worc:ac at: 21-Mar-2001 7:51
Frank,
commander looks the "business". I've compiled and got it running on my
Linux box.
I have a small question, how can I capture the output in REBOL of the
command I call?
eg
Rebol> call "psql -d dbname -c 'select * from tablename'"
This returns all the rows from tablename on STDOUT (?) but I don't see how I
can assign then to a REBOL word.
I would like to be able to do
Rebol> results: call "psql -d dbname -c 'select * from tablename'"
I will continue to investigate 'commander'
Regards
colinb
[13/16] from: fsievert:uos at: 21-Mar-2001 10:35
On Wed, 21 Mar 2001, Colin Brizell wrote:
> I have a small question, how can I capture the output in REBOL of the
> command I call?
>
> eg
>
> Rebol> call "psql -d dbname -c 'select * from tablename'"
>
> This returns all the rows from tablename on STDOUT (?) but I don't see how I
> can assign then to a REBOL word.
This is not possible at the moment. You can only call commands at the
moment but not get the output. It is possible to redirect the output into
a file
call "psql >out.tmp -d ....."
And read this file with REBOL.
read %out.tmp
I will add the feature to get the result and output of the call.
Commander.c is not ready.
CU,
Frank
[14/16] from: athena:pop3-dfw:myfirstlink at: 24-Mar-2001 10:35
127.0.0.0/8 has special attributes in the IP network. It is not
assigned to anyone so it can not be routed in the Internet except by
default routes nor can it get out of a router since no network
interfaces are configured with this address.
On the local LAN, potentially 127.0.0.1 could be directed to a specific
machine, but you have bigger problems than an attack on your machine if
it is coming from your internal network. Systems should always assume
that 127.x.x.x is destined for itself so it should be very difficult to
get a 127.x.x.x packet onto even the local network.
For internal machine communication between socket based applications
127.0.0.1 does not pose a serious threat. The real issue is activation
of the TCP or UDP port on which you intend to communicate. Any system
that can get to your machine can access the port. The "server" end of
the connection should verify that the "client" end is 127.0.0.1 and
reject any other connections from other IP addresses.
Harold Grovesteen
Deryk Robosson wrote:
[15/16] from: kracik:mbox:dkm:cz at: 24-Mar-2001 22:37
Hi Ryan,
I think that would be an overkill for calling commands from REBOL.
For now it will be just a quick hack. I lack both time and knowledge
to make it secure and reliable.
Regards,
Michal Kracik
Ryan Cole wrote:
[16/16] from: kracik:mbox:dkm:cz at: 24-Mar-2001 22:39
Thanks for the information. I can check that the client's address is
127.0.0.1. But as Frank pointed out, bigger problem is that another
user on the same machine can ask the server to execute any command for
him. I don't know how to solve that, apart from programming a telnet
daemon with user authentization as suggested by Ryan Cole.
--
Michal Kracik
Harold Grovesteen wrote:
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted