From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: RFC: (ice-9 sandbox) Date: Fri, 14 Apr 2017 12:58:06 +0200 Message-ID: <87tw5r6ytd.fsf@pobox.com> References: <87r31daj8n.fsf@pobox.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492167509 25851 195.159.176.226 (14 Apr 2017 10:58:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Apr 2017 10:58:29 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: guile-devel@gnu.org To: Freja Nordsiek Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Apr 14 12:58:25 2017 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cyyvo-0006d9-3w for guile-devel@m.gmane.org; Fri, 14 Apr 2017 12:58:24 +0200 Original-Received: from localhost ([::1]:52724 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cyyvt-0007kX-Tc for guile-devel@m.gmane.org; Fri, 14 Apr 2017 06:58:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54179) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cyyvj-0007kS-42 for guile-devel@gnu.org; Fri, 14 Apr 2017 06:58:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cyyvg-0002FX-0S for guile-devel@gnu.org; Fri, 14 Apr 2017 06:58:19 -0400 Original-Received: from pb-sasl1.pobox.com ([64.147.108.66]:55706 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cyyvf-0002FO-TU for guile-devel@gnu.org; Fri, 14 Apr 2017 06:58:15 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 501E16F9FD; Fri, 14 Apr 2017 06:58:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=CQdRExga+pAXGpfS67ZYT6X5FBk=; b=rZlK2J nP1tjj+eKQ7HAjNHYfzLyzvch+Jir8DokCo58NIGpzDOzrWB8+FxspKmtt5uhLnb +DEuPDQalgfrOsykkyNQq8u/Jp28iw2yCxk+IE5ouA/RxMzYnEAvFMm50HwQZ2mV wJp7c3EQh+DDFEMci26WSxJDAVf3P0f0CS5bw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=MBoyai2hlVKO/gshuivEegWwW+1o8XdL rFKfTxVlm1YFkvDy2odHls2d4nHOfTll82UyFeMZGpYn2ppDkrGkDpD7SIBYgXTN XEoyVDHxowx+LWb27pm8i0i6vbf0EAnLLhYs+fjzSKzhp0LEG1zUWl9cmqzq80Tn OcKsi2oN/v0= Original-Received: from pb-sasl1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 367FD6F9FA; Fri, 14 Apr 2017 06:58:15 -0400 (EDT) Original-Received: from clucks (unknown [88.160.190.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id F1EB76F9F9; Fri, 14 Apr 2017 06:58:13 -0400 (EDT) In-Reply-To: (Freja Nordsiek's message of "Thu, 6 Apr 2017 23:41:57 +0200") X-Pobox-Relay-ID: 41D69236-2101-11E7-8D66-07D2064AB293-02397024!pb-sasl1.pobox.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 64.147.108.66 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19106 Archived-At: On Thu 06 Apr 2017 23:41, Freja Nordsiek writes: > On the subject of ports and i/o, I have a few ideas. R6RS i/o in the > (rnrs io ports) module generally requires the port to be explicitly > given, rather than assuming current in or out if not given (though > rnrs io simple does make those assumptions). For many, it would be > impossible because they put the port as the first argument and a > required second argument afterwards. Looking at module/io/ports.scm in > Guile 2.2.x, it looks like the reading and writing procedures there > should be safe. Obviously, nothing that opens a file should be used, > nor the procedures to get current input, output, and error; but the > rest can be used. And this includes string and bytevector ports, which > could be very useful in the sandbox (I don't know about anyone else, > but I use string ports all the time). > > One question, is there a particular reason that guard is not exported? > It doesn't seem like it is as nasty as dynamic-wind with trying to > terminate, though maybe I am just not seeing how it could be used to > prevent the sandbox terminating the process. Having at least one > exception handling binding might be very helpful in a sandbox. These questions are related. There is nothing unsafe about "guard" specifically. Indeed the sandbox environment has "catch" and similar things. "guard" isn't in this default set because currently the set of bindings that (ice-9 sandbox) offers in *all-pure-and-impure-bindings* is subset of the bindings that are available by default. "guard" has to be imported via srfi-34. Likewise for r6rs port procedures. I think it's reasonable to have this limitation -- otherwise there's no point at which to stop. Other binding sets are of course possible. I would of course like I/O in the sandbox :) We could have versions of "display" et al that require their port argument; that would be a consistent with the strict-subset criteria. Andy