Opened 3 years ago

Last modified 3 years ago

#17361 new bug

Non-interactive ssh sessions don't have necessary environment variables

Reported by: maquak Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: - General Version: R1/beta3
Keywords: ssh sshd Cc:
Blocked By: #17360 Blocking:
Platform: All

Description

When using ssh for non-interactive session, environment variables used by runtime_loader are not set, PATH is set, but LIBRARY_PATH and ADDON_PATH are not.

This causes for example jam builds to fail when executed via non-interactive ssh:

runtime_loader: Cannot open file libroot.so(needed by /boot/system/bin/cat): No such file or directory

To reproduce:

> ssh user@192.168.0.100 env                                                                     
SHELL=/bin/bash
PWD=/boot/home
LOGNAME=user
HOME=/boot/home
SSH_CONNECTION=192.168.0.200 53891 192.168.0.100 22
USER=user
SHLVL=0
SSH_CLIENT=192.168.0.200 53891 22
PATH=.:/boot/home/config/non-packaged/bin:/boot/home/config/bin:/boot/system/non-packaged/bin:/boot/system/bin:/bin:/boot/system/apps:/boot/system/preferences
MAIL=/var/mail/user
_=/boot/system/bin/env

Expected: PATH, LIBRARY_PATH and ADDON_PATH set in environment.

Change History (6)

comment:1 by waddlesplash, 3 years ago

Blocked By: 17360 added

I just opened #17360 which is the "meta" ticket about this exact problem.

comment:2 by maquak, 3 years ago

#17360 is only partially related, I already did some investigation and:

  • sshd does not propagate it's own environment onto created sessions, instead it creates new environment from scratch with some variables that are used across all systems (implemented in do_setup_env fn). Even if I start sshd from my interactive shell, then ssh sessions do not inherit any of my shell's variables.
  • we could fix this for Haiku:

a) by patching do_setup_env to also set Haiku-specific variables, but it's another patch to maintain and it also requires that sshd itself is started with LIBRARY_PATH and ADDON_PATH set and most likely it's not (#17360)

b) by adding SetEnv to default sshd_config

I'll go with option b)

comment:3 by waddlesplash, 3 years ago

I note sshd does not have LD_LIBRARY_PATH in do_setup_env, but it does have PATH. That seems odd, how does that work on Linux then?

Option b) may be OK, but let's look at the other options first.

in reply to:  3 comment:4 by maquak, 3 years ago

Replying to waddlesplash:

I note sshd does not have LD_LIBRARY_PATH in do_setup_env, but it does have PATH. That seems odd, how does that work on Linux then?

I have only one Linux host to test and I don't have LD_LIBRARY_PATH set at all there. According to man for ld.so it just uses default directories if LD_LIBRARY_PATH is not set. I would kinda expect Haiku's loader to work similar, so your question got me thinking that maybe the problem I have with my build is not that LIBRARY_PATH is not set, but it's actually set during build to something weird (I think I've seen line like export LIBRARY_PATH="something:$LIBRARY_PATH"). I'll check this...

comment:5 by waddlesplash, 3 years ago

Yes, indeed, the problem is that Jam modifies LIBRARY_PATH in various places, so runtime_loader does not use its default directories.

comment:6 by maquak, 3 years ago

I tried to modify BuildSetup file to enforce that LIBRARY_PATH is set before overwriting it with broken value, but I failed with Jam. I give up, I'll just use source /system/boot/SetupEnvironment before running jam.

Version 0, edited 3 years ago by maquak (next)
Note: See TracTickets for help on using tickets.