guile --listen

guile --listen

[Andy Wingo]

Hello all,

I implemented a module, (system repl server), which exports routines to
listen on a socket for connections, and serve repls to clients, one
thread per client. The server can also be in a different thread.

I set the default socket type to TCP (on localhost only), and the
default port to be 37146. It sort of looks like "GUILE" if you look at
it upside down. But it's many digits, so if anyone has a different
preferred default port we can change that.

Now, to step somewhat more controversially... I added a command-line
option to Guile, --listen, which will cause Guile to listen on a socket
while it is running. You can --listen=1234 to set a specific port, or
--listen=/tmp/foo-socket to use a unix domain socket (though currently
we don't clean up that socket, which is probably a bug) or just --listen
to listen on localhost:37146.

The point is to allow any Guile program to easily add a backdoor. Of
course it's amusing to be able to "nc localhost 37146" and get a repl,
but I figured it will be best with Jao's Geiser emacs mode
(http://www.nongnu.org/geiser/). You can just tell emacs to connect to a
given port and there you are, hacking on your web server. With a
suitable SSH tunnel you could hack on your live web server that way.

Security-wise, using a localhost address can result in local users being
able to do anything your process can do, but for some use cases that's
OK. Presumably you are using some restricted user or something, and if
people have a local user I'm sure there's myriad kernel holes that are
more interesting than a Guile shell. Anyway, it's off by default, so it
shouldn't matter.

With Unix domain sockets you can do more permissions-type stuff, but
I'm not sure if Emacs' comint works with unix sockets.

Anyway, that's the deal. Carp now if the whole idea is offensive to you,
and perhaps we can take out the command-line arg. It would be nice to
be able to make any long-running Guile application hackable just with a
command-line argument, though :)

Cheers,

Andy
-- 
http://wingolog.org/

Re: guile --listen

[Ludovic Courtès]

Hello!

I’m a big fan of the idea, great!

One thing, though: we should register this nicely chosen port number at
IANA.  :-)

Thanks,
Ludo’.

Re: guile --listen

[Andy Wingo]

On Mon 11 Oct 2010 22:12, ludo@gnu.org (Ludovic Courtès) writes:

> One thing, though: we should register this nicely chosen port number at
> IANA.  :-)

Haha, sounds like fun :)

Does it really make sense though? Since most uses are for privileged
access, given the lack of auth, I wonder that it has a general use. Or
is it mostly a preventative registration, to reserve that port number?

A
-- 
http://wingolog.org/

Re: guile --listen

[Thien-Thi Nguyen]

() Andy Wingo <wingo@pobox.com>
() Sun, 10 Oct 2010 21:01:32 +0200

Hi Andy,

   Security-wise, using a localhost address can result in local users
   being able to do anything your process can do [...]

eep

   [...] It would be nice to be able to make any long-running Guile
   application hackable just with a command-line argument, though :)

I think each application should make this decision individually.
It's nice that the infrastructure is shared, but the command-line
argument for all Guile programs goes too far, IMHO.  Perhaps a
compromise would be to make a module that processes an application
specific command-line argument and hooks things up appropriately.

  (use-modules ((... parse-listener-command-line-option)
                #:select (maybe-listen)))
  
  (define ((maintain context) port initial-creds)
    ;; authentication, authorization
    (cond ((or (not (well-formed initial-creds))
               (not (mostly-harmless 
                      (negotiate port initial-creds))))
           (close-port port))
          (else
           ;; set up logging;
           ;; notify the main loop of a(nother) munger;
           ;; finally, enter app-specific repl
           ...)))
  
  (define (main args)
    (let ((app-context (...)))
      ;; do stuff that should not be interrupted
      ...
      ;; ok, be accomodating
      (maybe-listen args 
                    ;; command-line arg
                    '--maintenance-access
                    ;; what to do if recognized
                    (maintain app-context)
                    ;; what to do when done
                    close-port)
      ...))

This way the application that wants to can compose command-line
listener specification, interaction protocol, and timing of access
more flexibly, without imposing a potentially unwanted spy on
other Guile programs.

In summary, i like the idea and potential of the core, but not the
coarse-grained and indiscriminate top-level control.  Factor and
be free!

Re: guile --listen

[Andy Wingo]

On Tue 12 Oct 2010 10:47, Thien-Thi Nguyen <ttn@gnuvola.org> writes:

>    [...] It would be nice to be able to make any long-running Guile
>    application hackable just with a command-line argument, though :)
>
> I think each application should make this decision individually.

Each app can, by inspecting command-line args and running things from
(system repl repl). Strictly speaking this arg is no more "dangerous" to
an app than `-e'; simply more convenient.

It is not an argument to all guile-using programs, by the way, only to
Guile itself. If you have a script, all args after the script name are
given to the app, not to Guile.

Cheers,

Andy
-- 
http://wingolog.org/

Re: guile --listen

[Ludovic Courtès]

Hi,

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

>    Security-wise, using a localhost address can result in local users
>    being able to do anything your process can do [...]
>
> eep
>
>    [...] It would be nice to be able to make any long-running Guile
>    application hackable just with a command-line argument, though :)
>
> I think each application should make this decision individually.
> It's nice that the infrastructure is shared, but the command-line
> argument for all Guile programs goes too far, IMHO.

There’s the new (system repl server), which exports various mechanisms
that an application should be able to use in its own way, I think.

I view the command-line option as a handy way to debug an application
“when you know what you are doing”.

Thanks,
Ludo’.