The dchroot package makes an implicit assumption that GNU su is installed on the system. As I finally found out, gentoo has su from the shadow package, which lacks some of the su options which dchroot assumes exist. Reproducible: Always Steps to Reproduce: 1. Install dchroot, and set up an appropriate chrooted environment 2. Run (for example) dchroot "/bin/ls" to execute "/bin/ls" in the default chroot. Actual Results: $ dchroot /bin/ls (gen32) /bin/ls /bin/ls: /bin/ls: cannot execute binary file dchroot: Child exited non-zero. dchroot: Operation failed. Expected Results: in the case above dchroot should give me a listing of my home directory from inside the new chroot. Note that the error message "/bin/ls: cannot execute binary file" which appears above originates from bash (or the users login shell in general) because of the following series of calls: dchroot -(incorrectly calls)-> /bin/su -(calls)-> /bin/bash In general, dchroot *does* work when invoked with no arguments, and succeeds in bringing up a new shell in the chrooted invironment, as expected. It only fails when attempting to make use of some of the extra features available in GNU su. So, (IMHO) this function of dchroot is very useful in this sense and shouldn't be masked out... As requested in the bug submission form, here is the output from emerge info: $ emerge info Portage 2.0.51.19 (default-linux/amd64/2004.3, gcc-3.3.4, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r3 x86_64) ================================================================= System uname: 2.6.11-gentoo-r3 x86_64 12 Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Apr 9 2005, 22:30:56)] distcc 2.13 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.59-r3 sys-devel/automake: 1.8.3 sys-devel/binutils: 2.15.90.0.1.1-r3 sys-devel/libtool: 1.5.2-r5 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox strict userpriv usersandbox" GENTOO_MIRRORS="ftp://mirror.aarnet.edu.au/pub/gentoo/ ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://linux.thai.net/pub/mirrors/gentoo ftp://mirror.pacific.net.au/linux/Gentoo ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.au.gentoo.org/gentoo-portage" USE="amd64 X acpi alsa berkdb bitmap-fonts cdr crypt cscope cups curl dga dvd esd f77 fam fftw flac font-server fortran gd gdbm gif gphoto2 gpm gstreamer gtk gtk2 imagemagick imap imlib ipv6 java jp2 jpeg libwww lzw lzw-tiff mad mikmod mozilla mp3 mpeg ncurses nls nptl ogg oggvorbis opengl oss pam pdflib perl png python readline samba sdl slang spell ssl tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts usb userlocales vorbis xml xml2 xpm xrandr xv xvid zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Created attachment 57635 [details, diff] Patch to restore expected behavior of "dchroot prog_name" I have made what turns out to be a trivial patch to regain a little of the expected functionality and have attached it. Unfortunately, I believe that writing a fully general patch which could be given to the Debian people would involve removing the 'su' dependency and would as a result be significant coding effort (?)
Created attachment 57636 [details] ebuild for dchroot-0.11, incorporating patch I made the patch dchroot-0.11-prog_exec.patch against the 0.11 version of dchroot; here's the appropriately modified ebuild. (Please tell if almost trivially modified ebuilds like this are not welcome)
any way to make it detect at runtime which version of su the system has ? if it's too much of a hack i'll just use the patch you've already provided :)
Wouldn't a better solution be to add a compile time option? This would be easier and cleaner... I'll revisit the problem & try to fix it with some #ifdef WITH_GNU_SU preprocessor magic. Hopefully I'll be able to give this (relatively) non-kludgy version of the fix to the debian guys too.
Created attachment 57740 [details, diff] fix behaviour when calling non-gnu su Now for a proper fix of the problem. The dchroot-0.11-no_gnu_su patch excludes sections of the code conditional on the preprocessor symbol WITH_GNU_SU so it will now work with the version of su which comes with the shadow package
Created attachment 57741 [details, diff] fixes option-clobbering behaviour dchroot-0.11 grabs options which you wish to pass to the shell in the new chroot. (For example -c to execute a shell expression.) This patch adds the canonical -- option to prevent this.
Created attachment 57742 [details] ebuild for dchroot-0.11 with patches Finally, dchroot should now work as expected under a non-gnu version of /bin/su. This is an ebuild for the fixed version :) It was less work than I expected, but still quite a bit since this is my first non-trivial patch of someone else's program!
Finally my scripts for chrooting work fine with this version :) Thanks!
shadow-4.0.14 should fix this as it includes gnu-su options
Indeed, dchroot 0.10 seems to work fine now here
I'm not really sure this bug should be marked resolved. I have shadow-4.0.15, and I still get exactly the behavior described in the original bug report. Does the version of shadow inside the chroot matter, too?
(In reply to comment #11) > I'm not really sure this bug should be marked resolved. I have shadow-4.0.15, > and I still get exactly the behavior described in the original bug report. > Does the version of shadow inside the chroot matter, too? Yes. The version of /bin/su inside the chroot is the one which gets called by dchroot. (the issue should be insensitive to the version of su outside the chroot)
I have shadow 4.0.15 in my chroot and non-chroot, and dchroot 0.10 in my non-chroot, and yet the same "cannot execute binary file" thing happens. I'm afraid the bug hasn't fully gone away - hope I'm wrong. Help? Arch: i686 Time: Mon Apr 17 18:15:56 Term: /dev/pts/3 Jobs: 0 [ayqazi@big ~/apps/pcsx] $ emerge -vp shadow These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-apps/shadow-4.0.15 USE="nls pam -nousuid -skey" 0 kB Arch: x86_64 Time: Mon Apr 17 19:16:51 Term: /dev/pts/1 Jobs: 0 [ayqazi@big ~] $ emerge -vp dchroot These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-apps/dchroot-0.10 0 kB Arch: x86_64 Time: Mon Apr 17 19:17:35 Term: /dev/pts/1 Jobs: 0 [ayqazi@big ~] $ cat /etc/dchroot.conf 32 /32 Arch: x86_64 Time: Mon Apr 17 19:17:25 Term: /dev/pts/1 Jobs: 0 [ayqazi@big ~] $ linux32 dchroot ls (32) ls /bin/ls: /bin/ls: cannot execute binary file dchroot: Child exited non-zero. dchroot: Operation failed.
