Re: Openssh shared library problem
On Thu, 29 Jan 2009, Paul Holcomb wrote:
On my system, there is a problem with programs spawned from sshd and
shared library paths. This is most easily replicated by simply
trying to scp a file to the debian-interix machine:
--
$> scp <file> administrator@debian:/tmp
scp: error in loading shared libraries
libc.so.3.5: cannot open shared object file: No such file or directory
lost connection
--
Oh, this is very likely caused by your 64-bit environment. On 32-bit
interix everything is in /lib or /usr/lib, the default paths that
ld.so uses. But 64-bit probably has different paths for the 32-bit
stuff. I didn't test on 64-bit at all.
Did you happen to test with Rodney's sshd from interopsystems.com
if that one has the same problem? Or if not, you may find out, how
Rodney did it?
Or you try to put symlinks in /lib/ pointing to the real libc.so.3.5.
As there are no .so files on 64-bit, the names shouldn't clash.
This should be necessary only for the system .so files, as the
debian-interix stuff will get installed into /lib or /usr/lib
automatically (even if that is probably "wrong" on 64-bit).
(Using bash as your shell also causes this problem BTW)
It seems that the primary method of setting these paths (because
there is no ld.so.conf?) is making a system wide setting for
LD_LIBRARY_PATH=""usr/lib/x86:/usr/X11R6/lib". Because sshd doesn't
use pam or read /etc/environment, I thought the easiest way to fix
this would be to add LD_LIBRARY_PATH to the Windows environment
variables, as most of the other variables for SUA are populated
there.
However this variable isn't passed to sshd's children AFAICT because
of this line:
--openssh-4.7p1/session.c line 1064--
[in do_setup_env() ]
/* these are the interix directory
variables... */
"INTERIX_ROOT",
"INTERIX_ROOT_WIN",
"SFUDIR",
"SFUDIR_WIN",
"SUA_ROOT",
"SUA_ROOT_WIN",
"OPENNT_ROOT",
--> /* LD_LIBRARY_PATH required? */
NULL};
--
I verified that if I add LD_LIBRARY_PATH to AcceptEnv in sshd_config
(generally a bad idea), and pass that variable from my ssh client
with SendEnv, the shared library problems go away.
So, I was attempting to comment back the line is session.c and
rebuild, but I wasn't even able to do a build from the deb source
before running into a number of issues, including this header
related one from configure during the dpkg-buildpackage of openssh.
--
checking dirent.h presence... yes
configure: WARNING: dirent.h: present but cannot be compiled
configure: WARNING: dirent.h: check for missing prerequisite headers?
configure: WARNING: dirent.h: see the Autoconf documentation
configure: WARNING: dirent.h: section "Present But Cannot Be Compiled"
configure: WARNING: dirent.h: proceeding with the preprocessor's result
configure: WARNING: dirent.h: in the future, the compiler will take precedence
configure: WARNING: ## ------------------------------------------- ##
configure: WARNING: ## Report this to openssh-unix-dev@mindrot.org ##
configure: WARNING: ## ------------------------------------------- ##
--
I did all my builds on a 32-bit system, more precisely on SFU 3.5, for
best compatibility. Maybe you can setup a chroot environment with all
the SFU 3.5 stuff in it and build within that. I successfully do
that on Vista 32-bit.
The problem with other, even 32-bit, interix versions might be that
the program to be build gets linked to the newest libc, but some
external .so lib which the program needs is linked to the 3.5 libc.
Before I go in detail any further, is there something obvious that
I'm missing? Nothing has compiled as in the build logs :)
The Windows OS I am using is Windows Server 2003 64 bit R2 SP2, with
all automatic updates applied that are available.
Martin
Reply to: