Re: guile --listen

[Thien-Thi Nguyen]

() Andy Wingo <address@hidden>
() 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!