sshuttle /usr/bin/env

  • Done
  • quality assurance status badge
Details
3 participants
  • Marius Bakke
  • Tobias Geerinckx-Rice
  • Nam Nguyen
Owner
unassigned
Submitted by
Nam Nguyen
Severity
normal
N
N
Nam Nguyen wrote on 27 Sep 2018 20:23
(address . bug-guix@gnu.org)
20180927182323.GA30836@antelope
sshuttle is a python program that uses /usr/bin/env at line 196 of:
/gnu/store/...-sshuttle-0.78.4/lib/python3.6/site-packages/sshuttle/client.py
['sudo', '-p', '[local sudo] Password: ', '/usr/bin/env',

Trying to run sshuttle on GuixSD results in:
$ sshuttle -r user@server.com 0/0 -x server.com
sudo: /usr/bin/env: command not found

Here is a potential fix that I recycled from sshoot's recipe. I tested it,
and it works.

$ diff ~/.config/guix/current/share/guile/site/2.2/gnu/packages/vpn.scm ~/vpn.scm
349a350,357
Toggle quote (9 lines)
> (arguments
> '(#:phases
> (modify-phases %standard-phases
> (add-after 'unpack 'patch-paths
> (lambda _
> (substitute* "sshuttle/client.py"
> (("/usr/bin/env") (which "env")))
> #t)))))

Cheers,
Nam
T
T
Tobias Geerinckx-Rice wrote on 27 Sep 2018 21:11
(name . Nam Nguyen)(address . namn@berkeley.edu)(address . 32855@debbugs.gnu.org)
87va6qhi1a.fsf@tobias.gr
Hullo,

Thanks for the report!

Nam Nguyen wrote:
Toggle quote (9 lines)
> sshuttle is a python program that uses /usr/bin/env at line 196
> of:
> /gnu/store/...-sshuttle-0.78.4/lib/python3.6/site-packages/sshuttle/client.py
> ['sudo', '-p', '[local sudo] Password: ', '/usr/bin/env',
>
> Trying to run sshuttle on GuixSD results in:
> $ sshuttle -r user@server.com 0/0 -x server.com
> sudo: /usr/bin/env: command not found

This means that sshuttle on vanilla GuixSD has been broken ever
since I added it in 2016, which saddens me. I guess nobody else
uses it or, like me, they happen to also have a /usr/bin/env
symlink.

Toggle quote (17 lines)
> Here is a potential fix that I recycled from sshoot's recipe. I
> tested it,
> and it works.
>
> $ diff
> ~/.config/guix/current/share/guile/site/2.2/gnu/packages/vpn.scm
> ~/vpn.scm
> 349a350,357
>> (arguments
>> '(#:phases
>> (modify-phases %standard-phases
>> (add-after 'unpack 'patch-paths
>> (lambda _
>> (substitute* "sshuttle/client.py"
>> (("/usr/bin/env") (which "env")))
>> #t)))))

I'll push this soon. Is it all right if I mention your name &
e-mail in the commit message?

Kind regards,

T G-R
N
N
Nam Nguyen wrote on 27 Sep 2018 21:22
(address . 32855@debbugs.gnu.org)
20180927192218.GA11125@antelope
Yes, feel free to mention my name and e-mail. Thank you for your work
packaging it.
T
T
Tobias Geerinckx-Rice wrote on 28 Sep 2018 00:04
(name . Nam Nguyen)(address . namn@berkeley.edu)(address . 32855-done@debbugs.gnu.org)
87o9ciha1x.fsf@tobias.gr
Nam Nguyen wrote:
Toggle quote (2 lines)
> Yes, feel free to mention my name and e-mail.

Pushed as 6a6f7488df1794828e1845eaaf2c1c911c8e3e54.

Kind regards,

T G-R
Closed
N
N
Nam Nguyen wrote on 30 Sep 2018 00:40
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(address . 32855@debbugs.gnu.org)
20180929224001.GA10179@antelope
Hi Tobias,

After testing, I think the /bin/sh substitution introduced a regression.

Lines in question:
(substitute* "sshuttle/ssh.py"
;; Perhaps this is unreachable, but don't let's take risks.
(("/bin/sh") (which "sh")))

$ sshuttle -r user <at> 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 find
/gnu/store/.../bin/sh but it doesn't exst. My local client is running
GuixSD. The only requirements on the server side should be Python. Should
those lines should be removed? I tested without, and it seems to work okay,
at least for my particular setup: GuixSD client --> non-GuixSD server.

I suppose we have to state the assumptions of whether the client and
server are running Guix or not, and arrive at good defaults.
T
T
Tobias Geerinckx-Rice wrote on 30 Sep 2018 13:52
(name . Nam Nguyen)(address . namn@berkeley.edu)(address . 32855@debbugs.gnu.org)
87h8i7cicn.fsf@tobias.gr
Hullo,

Nam Nguyen wrote:
Toggle quote (9 lines)
> Hi Tobias,
>
> After testing, I think the /bin/sh substitution introduced a
> regression.
>
> Lines in question:
> (substitute* "sshuttle/ssh.py"
> ;; Perhaps this is unreachable, but don't let's take risks.

Oh, the irony.

Toggle quote (2 lines)
> (("/bin/sh") (which "sh")))

This is just wrong: it calls the client's /gnu/store/.../sh on the
server.

Toggle quote (8 lines)
> $ sshuttle -r user <at> 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
> find
> /gnu/store/.../bin/sh but it doesn't exst.

That's a good point (all my remotes run GuixSD, hiding the bug).

Toggle quote (2 lines)
> The only requirements on the server side should be Python.

It's all well & good for upstream to say that (they do), but if
they explicitly call /bin/sh on the server then it's just not
true. A POSIX-compliant 'sh' was always an unstated server-side
dependency, and Guix happens to be very good at finding (and
breaking :-) those.

The hard-coded '/bin/' kluge was accepted later¹. Can't fathom
why. If brianmay's last comment is still true they'll accept the
correct 'exec sh' solution too.

Could you check whether replacing '(which "sh")' with '"sh"'
works? It does for me.

Toggle quote (5 lines)
> Should those lines should be removed? I tested without, and it
> seems to work okay,
> at least for my particular setup: GuixSD client --> non-GuixSD
> server.

Wouldn't that break [any client -> vanilla GuixSD server] cases?

No denying that this regression needs to be fixed,
though. Apologies for breaking your 'flow.

Toggle quote (4 lines)
> I suppose we have to state the assumptions of whether the client
> 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
Internet.

Kind regards,

T G-R

N
N
Nam Nguyen wrote on 30 Sep 2018 16:45
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(address . 32855@debbugs.gnu.org)
20180930144505.GA996@antelope
Toggle quote (1 lines)
> This is just wrong: it calls the client's /gnu/store/.../sh on the server.
Thanks for identifying the problem. Your solution sounds good.

Toggle quote (2 lines)
> Could you check whether replacing '(which "sh")' with '"sh"' works? It does
> for me.
Yes, this works in my testing.

Toggle quote (2 lines)
> A POSIX-compliant 'sh' was always an unstated server-side dependency,
> and Guix happens to be very good at finding (and breaking :-) those.
Guix is great, and I am enjoying learning more about it! I suppose these
are the challenges that come with making software portable.
M
M
Marius Bakke wrote on 6 Oct 2018 16:19
(address . 32855@debbugs.gnu.org)
87va6fi2dx.fsf@fastmail.com
Tobias Geerinckx-Rice <me@tobias.gr> writes:

Toggle quote (7 lines)
>> Should those lines should be removed? I tested without, and it
>> seems to work okay,
>> at least for my particular setup: GuixSD client --> non-GuixSD
>> server.
>
> Wouldn't that break [any client -> vanilla GuixSD server] cases?

Note that /bin/sh is present even on vanilla GuixSD.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAlu4xGoACgkQoqBt8qM6
VPpoxQf+O6o2UNk0A8xdyRJKOJ3aLQVJHexpZDBLotprga3WyGrzXlUuNTOAxWgL
glywjWxQpQi6VHFhZlKOin0xh2ULKoMUdSEWDrCLcJnA+h8sONFeYE2oD+ZEK4YA
3n1CsRUfxeGWY5GtOAqrDXeKnqpOqQ7VbsdoNXbtv7qP2YY6jyNHIBffKzSrf84S
oyBeByf2tIzjKwoq5DkKfE6R9r+S8lqiG+DtlxhZ7BNjwLPkZhO0I/q7WaZlb+9u
Qt1C8smIjdfX7nL8MkjobcQ2OOj6kSMv7E/+gqx+r2nd5ARV3E1Cj9LqNGiWwg4r
R9kF1M1aR8Hi2h/j083XSb0JpBVK7w==
=fjAp
-----END PGP SIGNATURE-----

T
T
Tobias Geerinckx-Rice wrote on 6 Oct 2018 16:49
(name . Marius Bakke)(address . mbakke@fastmail.com)
875zyfgmeo.fsf@tobias.gr
Marius,

Marius Bakke wrote:
Toggle quote (2 lines)
> Note that /bin/sh is present even on vanilla GuixSD.

Thanks. I should probably give this vanilla GuixSD of which you
speak a try some time :-)

Kind regards,

T G-R
?