unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Thien-Thi Nguyen <ttn@gnuvola.org>
To: Andy Wingo <wingo@pobox.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: guile --listen
Date: Tue, 12 Oct 2010 10:47:57 +0200	[thread overview]
Message-ID: <87sk0b4x1e.fsf@ambire.localdomain> (raw)
In-Reply-To: <m339sdg9df.fsf@unquote.localdomain> (Andy Wingo's message of "Sun, 10 Oct 2010 21:01:32 +0200")

() 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!



  parent reply	other threads:[~2010-10-12  8:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-10 19:01 guile --listen Andy Wingo
2010-10-11 20:12 ` Ludovic Courtès
2010-10-11 21:05   ` Andy Wingo
2010-10-12  8:47 ` Thien-Thi Nguyen [this message]
2010-10-12  9:40   ` Andy Wingo
2010-10-12  9:52   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sk0b4x1e.fsf@ambire.localdomain \
    --to=ttn@gnuvola.org \
    --cc=guile-devel@gnu.org \
    --cc=wingo@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).