Closed andrewg-felinemenace closed 13 years ago
I'm migrating existing code to --bin/--source. Everything that comes from the host will be called --bin-* and --sources-* for sources (or it could be called --host-* for that matter). So I like the idea of having a --bin-dropbear/--source-dropbear. To fix this issue for --source-dropbear maybe it would be possible to identify the missing libs that get pulled by nsswitch.conf and add an option (and maybe deps as well) to ship them. I'm not fond of libs options (zlib glibc etc) but we can't do anything without it, so adding a few more is no big deal.
I'll think about it this weekend and come back to you with more ideas and code asap.
Thanks for your help
"The binary will call getaddrinfo() and as a result will try to read /etc/nsswitch.conf and try to load libraries (and completely fail in the process)"
ah probably that's what you were referring to.
a - src/modes/ofb/ofb_getiv.o
a - src/modes/ofb/ofb_setiv.o
a - src/modes/ofb/ofb_start.o
x86_64-pc-linux-gnu-ranlib libtomcrypt.a
make[1]: Leaving directory /var/tmp/portage/net-misc/dropbear-0.53.1/work/dropbear-0.53.1/libtomcrypt' x86_64-pc-linux-gnu-gcc -Wl,-O1 -Wl,--as-needed -static -o dropbear dbutil.o buffer.o dss.o bignum.o signkey.o rsa.o random.o queue.o atomicio.o compat.o fake-rfc2553.o common-session.o packet.o common-algo.o common-kex.o common-channel.o common-chansession.o termcodes.o loginrec.o tcp-accept.o listener.o process-packet.o common-runopts.o circbuffer.o -lcrypt svr-kex.o svr-algo.o svr-auth.o sshpty.o svr-authpasswd.o svr-authpubkey.o svr-authpubkeyoptions.o svr-session.o svr-service.o svr-chansession.o svr-runopts.o svr-agentfwd.o svr-main.o svr-x11fwd.o svr-tcpfwd.o svr-authpam.o libtomcrypt/libtomcrypt.a libtommath/libtommath.a -lutil -lz x86_64-pc-linux-gnu-gcc -Wl,-O1 -Wl,--as-needed -static -o dbclient dbutil.o buffer.o dss.o bignum.o signkey.o rsa.o random.o queue.o atomicio.o compat.o fake-rfc2553.o common-session.o packet.o common-algo.o common-kex.o common-channel.o common-chansession.o termcodes.o loginrec.o tcp-accept.o listener.o process-packet.o common-runopts.o circbuffer.o cli-algo.o cli-main.o cli-auth.o cli-authpasswd.o cli-kex.o cli-session.o cli-service.o cli-runopts.o cli-chansession.o cli-authpubkey.o cli-tcpfwd.o cli-channel.o cli-authinteract.o cli-agentfwd.o list.o libtomcrypt/libtomcrypt.a libtommath/libtommath.a -lutil -lz x86_64-pc-linux-gnu-gcc -Wl,-O1 -Wl,--as-needed -static -o dropbearkey dbutil.o buffer.o dss.o bignum.o signkey.o rsa.o random.o queue.o atomicio.o compat.o fake-rfc2553.o dropbearkey.o gendss.o genrsa.o libtomcrypt/libtomcrypt.a libtommath/libtommath.a -lutil -lz x86_64-pc-linux-gnu-gcc -Wl,-O1 -Wl,--as-needed -static -o dropbearconvert dbutil.o buffer.o dss.o bignum.o signkey.o rsa.o random.o queue.o atomicio.o compat.o fake-rfc2553.o dropbearconvert.o keyimport.o libtomcrypt/libtomcrypt.a libtommath/libtommath.a -lutil -lz dbutil.o: In function
dropbear_listen':
dbutil.c:(.text+0x74f): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
common-session.o: In function fill_passwd': common-session.c:(.text+0x9e8): warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking cli-kex.o: In function
recv_msg_kexdh_reply':
cli-kex.c:(.text+0x6b5): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
dbutil.o: In function dropbear_listen': dbutil.c:(.text+0x74f): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking svr-chansession.o: In function
execchild':
svr-chansession.c:(.text+0x777): warning: Using 'initgroups' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
sshpty.o: In function pty_setowner': sshpty.c:(.text+0x307): warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking common-session.o: In function
fill_passwd':
common-session.c:(.text+0x9e8): warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
dbutil.o: In function dropbear_listen': dbutil.c:(.text+0x74f): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking svr-authpasswd.o: In function
svr_auth_password':
svr-authpasswd.c:(.text+0x25): warning: Using 'getspnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
svr-authpasswd.c:(.text+0x6d): undefined reference to crypt' collect2: ld returned 1 exit status make: **\* [dropbear] Error 1 make: **\* Waiting for unfinished jobs.... dropbearkey.o: In function
printpubkey':
dropbearkey.c:(.text+0xf1): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
dbutil.o: In function `dropbear_listen':
dbutil.c:(.text+0x74f): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
emake failed
Failed to emerge net-misc/dropbear-0.53.1, Log file:
'/var/tmp/portage/net-misc/dropbear-0.53.1/temp/build.log' z13 ~ #
Yep. If you use that binary, it won't work due to static / dlopen()'ing files.
ok but then it's more an upstream issue. http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2011q1/001093.html
0.53.1 was supposed to fix this. I'll try upper versions. http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2011q1/001094.html
But according to vapier, it still fails: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2011q1/001096.html which is what we experience here I think.
Nothing much we can do.
If you allow host dropbear/glibc/zlib/ncurses, you can compile it on the host dynamically.
To support that though, kigen needs to remove an isstatic() check though. (which i commented out on my system to make it work)
if os.path.isfile(dropbear_sbin) and self.hostbin is True: # and isstatic(dropbear_sbin, self.verbose):
ok I see. Will fix that.
Thanks
actually, I'm planning on adding an extra option to ship detected libs from dynamically linked bins. By default, it wants static ones but if say --ship-dynlibs is passed it'll parse ldd and add relevant libs. This is mainly because there is not always a -static USE flag for a given Portage --bin-feature and it would prevent user from re merging its dynamically linked host bin (kigen can work out without user forced to emerge again). I'm thinking of a bin/source both of which can be static/dynamic linked type of thing. So in theory that should take care of the issue.
I'm just figuring out that I can't get a dynamically linked binary with its libs in this case screen to work with a static busybox :( I get from ash:
/bin/ash: file not found
but the binary is there, size is ok I can vi it like any other binary. All other binaries work except this one dynamically linked with its libs.
does your dynamic dropbear work with the static busybox? if yes why? and why not screen?
Dropbear works fine for me, no issues. I don't use screen in my initrd, so I have no idea there. I would suggest using strace, and seeing what happens on the execve() call. If the execve call fails, then it's an issue with the libraries (perhaps it's hard coded to look somewhere, or you've copied libblah.so and not libblah.so.2.3, etc).
tried strace and all I could think of without any help. I've read somewhere that this might be related to using a static busybox with dynamic files in general. But you clearly confirm that dropbear dynamic works with a static busybox. So the problem must be somewhere else.. I was scared to realize everything had to be either static or dynamic. Glad it's not the case.
Ohh, well I'll find it out in due time ;)
Thanks for the feedback
for me as a reminder:
http://lists.busybox.net/pipermail/uclibc/2009-May/042483.html
I probably need more libs in /lib to get screen dynamic to work out of the box in a static busybox.
z13 ~ # strace /var/tmp/kigen/work/initramfs-bin-screen-temp/bin/screen 2>&1 | grep open open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib64/libcrypt.so.1", O_RDONLY) = 3 open("/lib64/libncursesw.so.5", O_RDONLY) = 3 open("/lib64/libpam.so.0", O_RDONLY) = 3 open("/lib64/libc.so.6", O_RDONLY) = 3 open("/lib64/libdl.so.2", O_RDONLY) = 3 open("/proc/self/loginuid", O_RDONLY) = 3 open("/etc/nsswitch.conf", O_RDONLY) = 3 open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib64/libnss_compat.so.2", O_RDONLY) = 3 open("/lib64/libnsl.so.1", O_RDONLY) = 3 open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib64/libnss_nis.so.2", O_RDONLY) = 3 open("/lib64/libnss_files.so.2", O_RDONLY) = 3 open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3 open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3 open("/etc/shadow", O_RDONLY|O_CLOEXEC) = 3 open("/dev/pts/1", O_RDWR|O_NONBLOCK) = 3 z13 ~ # ls -l /var/tmp/kigen/work/initramfs-/lib/ -rwxr-xr-x 1 root root 136616 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-glibc-temp/lib/ld-linux-x86-64.so.2 -rwxr-xr-x 1 root root 117748 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-glibc-temp/lib/ld-linux.so.2 -rwxr-xr-x 1 root root 1604816 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-glibc-temp/lib/libc.so.6 -rwxr-xr-x 1 root root 34920 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-glibc-temp/lib/libcrypt.so.1 -rwxr-xr-x 1 root root 530560 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-glibc-temp/lib/libm.so.6 -rwxr-xr-x 1 root root 88880 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-glibc-temp/lib/libnsl.so.1 -rwxr-xr-x 1 root root 31432 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-glibc-temp/lib/libnss_compat.so.2 -rwxr-xr-x 1 root root 22744 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-glibc-temp/lib/libnss_dns.so.2 -rwxr-xr-x 1 root root 51544 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-glibc-temp/lib/libnss_files.so.2 -rwxr-xr-x 1 root root 43376 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-glibc-temp/lib/libnss_nis.so.2 -rwxr-xr-x 1 root root 84624 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-glibc-temp/lib/libresolv.so.2 -rwxr-xr-x 1 root root 10464 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-glibc-temp/lib/libutil.so.1 -rwxr-xr-x 1 root root 345936 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-libncurses-temp/lib/libncurses.so.5 -rwxr-xr-x 1 root root 136616 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-screen-temp/lib/ld-linux-x86-64.so.2 -rwxr-xr-x 1 root root 1604816 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-screen-temp/lib/libc.so.6 -rwxr-xr-x 1 root root 34920 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-screen-temp/lib/libcrypt.so.1 -rwxr-xr-x 1 root root 14512 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-screen-temp/lib/libdl.so.2 -rwxr-xr-x 1 root root 395472 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-screen-temp/lib/libncursesw.so.5 -rwxr-xr-x 1 root root 55712 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-screen-temp/lib/libpam.so.0 -rwxr-xr-x 1 root root 96632 Jun 15 14:16 /var/tmp/kigen/work/initramfs-bin-zlib-temp/lib/libz.so.1
/var/tmp/kigen/work/initramfs-keymaps-temp/lib/keymaps: total 8 -rwxr-xr-x 1 root root 2823 Jun 15 14:16 be.map -rwxr-xr-x 1 root root 2823 Jun 15 14:16 fr.map -rwxr-xr-x 1 root root 593 Jun 15 14:16 keymapList -rwxr-xr-x 1 root root 2823 Jun 15 14:16 us.map
/var/tmp/kigen/work/initramfs-modules-2.6.38-gentoo-r5-temp/lib/modules: total 0 drwxr-xr-x 1 root root 592 Jun 15 14:16 2.6.38-gentoo-r5
/var/tmp/kigen/work/initramfs-source-luks-temp/lib/luks: total 0 z13 ~ #
seems like only libpam.so.0 is not there. But that should not be a problem though... still no clue why dyn screen fails to run :(
BUT actually libpam is there....pfffff
ah, file not found probably refers to a missing lib when ld-linux checks for libpam.so.1. (not sure though just a wild guess) if screen merged from portage, it'll be dynamic with +pam USE flag. Hence requesting libpam.so.1 at run time.
As I've compiled busybox with -static, pam is disabled for busybox!! So BB wouldn't support the libpam calls somehow or just BB has nothing to do with that. It may just be that +pam thing that screws it all.
could that be the reason? I should try to recompile screen with -pam rerun kigen --bin-screen --dynlibs and test it from the initramfs. If I'm right, it should work. Else, well I'll see tomorrow ;)
it's gotta be a lib issue for sure.
BUT actually libpam is there....pfffff... forget it, I'm pissed, will see that next week instead :(
damn it!
I'm just testing from a virtualbox VM and 'kigen --bin-screen --dynlibs' works perfect! The screen dynamic library works ok, I can screen multiple sessions go back forth, it's all good.
Strange though.. for 2 days I get '/bin/ash: file not found' when I call on screen and now it works. I think I'll see this stuff again..;(
There's an issue with static dropbear under Gentoo when compiling statically. The binary will call getaddrinfo() and as a result will try to read /etc/nsswitch.conf and try to load libraries (and completely fail in the process). Logging in will completely fail with no password comparsion etc done.
The hackiest approach is to compile dynamically on the host, and comment out isstatic() check in source code. Perhaps adding host-dropbear and requiring glibc/ncurses/etc will work though. What are your thoughts on that approach?