From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tobias Geerinckx-Rice Subject: bug#32855: sshuttle /usr/bin/env Date: Sun, 30 Sep 2018 13:52:56 +0200 Message-ID: <87h8i7cicn.fsf@tobias.gr> References: <20180927182323.GA30836@antelope> <20180927192218.GA11125@antelope> <87o9ciha1x.fsf@tobias.gr> <20180929224001.GA10179@antelope> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6aIX-0004fh-Mn for bug-guix@gnu.org; Sun, 30 Sep 2018 07:54:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g6aIU-0000cm-Fk for bug-guix@gnu.org; Sun, 30 Sep 2018 07:54:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:55223) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g6aIU-0000cg-8g for bug-guix@gnu.org; Sun, 30 Sep 2018 07:54:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g6aIU-0000G6-07 for bug-guix@gnu.org; Sun, 30 Sep 2018 07:54:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <20180929224001.GA10179@antelope> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Nam Nguyen Cc: 32855@debbugs.gnu.org Hullo, Nam Nguyen wrote: > Hi Tobias, > > After testing, I think the /bin/sh substitution introduced a=20 > regression. > > Lines in question: > (substitute* "sshuttle/ssh.py" > ;; Perhaps this is unreachable, but don't let's take risks. Oh, the irony. > (("/bin/sh") (which "sh"))) This is just wrong: it calls the client's /gnu/store/.../sh on the=20 server. > $ sshuttle -r user server.com 0/0 -x server.com > ksh: /gnu/store/rb...-bash-minimal-4.4.19/bin/sh: not found > client: fatal: server died with error code 127 > > The server I am sshing to is not running GuixSD. It is trying to=20 > find > /gnu/store/.../bin/sh but it doesn't exst. That's a good point (all my remotes run GuixSD, hiding the bug). > The only requirements on the server side should be Python. It's all well & good for upstream to say that (they do), but if=20 they explicitly call /bin/sh on the server then it's just not=20 true. A POSIX-compliant 'sh' was always an unstated server-side=20 dependency, and Guix happens to be very good at finding (and=20 breaking :-) those. The hard-coded '/bin/' kluge was accepted later=C2=B9. Can't fathom=20 why. If brianmay's last comment is still true they'll accept the=20 correct 'exec sh' solution too. Could you check whether replacing '(which "sh")' with '"sh"'=20 works? It does for me. > Should those lines should be removed? I tested without, and it=20 > seems to work okay, > at least for my particular setup: GuixSD client --> non-GuixSD=20 > server. Wouldn't that break [any client -> vanilla GuixSD server] cases? No denying that this regression needs to be fixed,=20 though. Apologies for breaking your 'flow. > I suppose we have to state the assumptions of whether the client=20 > and > server are running Guix or not, and arrive at good defaults. I'd like to avoid such assumptions in general, and entirely on the=20 Internet. Kind regards, T G-R 1. https://github.com/sshuttle/sshuttle/pull/77