[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

 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... */
-->                      /* LD_LIBRARY_PATH required? */


 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.


Reply to: