() Andy Wingo <[email protected]>
() 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!
