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!
next prev 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).