Yesterday I upgraded shadow from 4.0.3-rsomething to 4.0.4.1-r3 and suddenly none of the programs are setuid root anymore. I have pam in my USE flags. otherland /usr/portage/sys-apps/shadow # ls -l `equery files shadow | grep /bin/ | cut -d' ' -f1` -rwxr-xr-x 1 root root 6508 Jul 4 18:56 /bin/groups -rwsr-sr-x 1 root root 22032 Jul 4 18:56 /bin/su -rwxr-xr-x 1 root root 35800 Jul 4 18:56 /usr/bin/chage -rwxr-xr-x 1 root root 29508 Jul 4 18:56 /usr/bin/chfn -rwxr-xr-x 1 root root 25680 Jul 4 18:56 /usr/bin/chsh -rwxr-xr-x 1 root root 17240 Jul 4 18:56 /usr/bin/expiry -rwxr-xr-x 1 root root 8268 Jul 4 18:56 /usr/bin/faillog -rwxr-xr-x 1 root root 35100 Jul 4 18:56 /usr/bin/gpasswd -rwxr-xr-x 1 root root 6272 Jul 4 18:56 /usr/bin/lastlog -rwxr-xr-x 1 root root 21240 Jul 4 18:56 /usr/bin/newgrp -rwxr-xr-x 1 root root 26424 Jul 4 18:56 /usr/bin/passwd lrwxrwxrwx 1 root root 6 Jul 4 18:56 /usr/bin/sg -> newgrp The su app I chmodded manually to get some stuff working. This might be related to bug 47208 if somebody tried to "fix" it. Reproducible: Always Steps to Reproduce: Portage 2.0.50-r8 (default-x86-1.4, gcc-3.3.3, glibc-2.3.3.20040420-r0, 2.6.5-gentoo-r1) ================================================================= System uname: 2.6.5-gentoo-r1 i686 AMD Athlon(tm) Processor Gentoo Base System version 1.4.16 distcc 2.13 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-tbird -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/kde/cvs/share/config /usr/lib/mozilla/defaults/pref /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="-march=athlon-tbird -O2 -pipe" DISTDIR="/var/cache/portage/distfiles" FEATURES="autoaddcvs ccache distcc" GENTOO_MIRRORS="http://ftp.easynet.nl/mirror/gentoo/ http://gentoo.inode.at/" MAKEOPTS="-j2" PKGDIR="/var/cache/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/mss/.portage/mortage /usr/local/portage-overlay/misc /usr/local/portage-overlay/kde-cvs" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow X aavm acl acpi acpi4linux alsa apache2 apm applypatches arts artswrappersuid avi berkdb cdr crypt cups curl dga directfb dvd dvdr encode esd ethereal expat faad fbcon foomaticdb gd gdbm geoip gif gphoto2 gpm gtk gtk2 hbci imap imlib ipv6 irda java javascript jpeg kde ldap libg++ libwww mad maildir mikmod mmx motif mozilla moznoirc mpeg ncurses nls odbc oggvorbis opengl operanom2 oss pam pda pdflib perl png python qt quicktime readline samba scanner sdl slang spell sse ssl svga tcltk tcpd tetex tiff truetype usagi usb video_cards_radeon wmf x86 xinerama xml xml2 xmms xv xvid zlib"
I merged 4.0.4.1-r2 two days ago and here is what I get.. [ebuild U ] sys-apps/shadow-4.0.4.1-r3 [4.0.4.1-r2] -debug (-nls) (-pam) (-selinux) +uclibc 0 kB epm -q -l shadow | xargs file | grep ELF | cut -d : -f 1 | xargs ls -ld | grep ws -rws--x--x 1 root root 33196 Jul 3 05:20 /bin/su -rws--x--x 1 root root 37244 Jul 3 05:20 /usr/bin/chage -rws--x--x 1 root root 31244 Jul 3 05:20 /usr/bin/chfn -rws--x--x 1 root root 29856 Jul 3 05:20 /usr/bin/chsh -rws--x--x 1 root root 17692 Jul 3 05:20 /usr/bin/expiry -rws--x--x 1 root root 38120 Jul 3 05:20 /usr/bin/gpasswd -rws--x--x 1 root root 21020 Jul 3 05:20 /usr/bin/newgrp -rws--x--x 1 root root 39080 Jul 3 05:20 /usr/bin/passwd
Neither -r2, nor FEATURES=sfparms, nor USE=-pam, nor FEATURES=nostrip did change anything. The weird thing is that I can see a call to for i in chage chfn chsh expiry gpasswd newgrp passwd; do \ chmod 4755 /var/tmp/portage/shadow-4.0.4.1-r3/image//usr/bin/$i; \ done in the 'make install'/'ebuild ... install' step. Though the files in the image dir end up without the suid flag. If I execute the command above manually, everything works fine. This is all very weird...
try shadow-4.0.4.1-r4, they are installed with 4711 permissions now: -rws--x--x 1 root root 21620 Oct 7 20:00 /bin/su
I don't think so. This bug needs reopening, and title updated. I upgraded today to shadow-4.0.4.1-r4, and $ ls -l `equery files shadow | grep /bin/ | cut -d' ' -f1` -rwxr-xr-x 1 root root 6.8k Oct 17 14:06 /bin/groups* -rwx--x--x 1 root root 27k Oct 17 14:06 /bin/passwd* -rwx--x--x 1 root root 23k Oct 17 14:06 /bin/su* -rwx--x--x 1 root root 37k Oct 17 14:06 /usr/bin/chage* -rwx--x--x 1 root root 30k Oct 17 14:06 /usr/bin/chfn* -rwx--x--x 1 root root 26k Oct 17 14:06 /usr/bin/chsh* -rwx--x--x 1 root root 18k Oct 17 14:06 /usr/bin/expiry* -rwxr-xr-x 1 root root 8.2k Oct 17 14:06 /usr/bin/faillog* -rwx--x--x 1 root root 37k Oct 17 14:06 /usr/bin/gpasswd* -rwxr-xr-x 1 root root 6.2k Oct 17 14:06 /usr/bin/lastlog* -rwx--x--x 1 root root 25k Oct 17 14:06 /usr/bin/newgrp* lrwxrwxrwx 1 root root 16 Oct 17 14:06 /usr/bin/passwd -> ../../bin/passwd* lrwxrwxrwx 1 root root 6 Oct 17 14:06 /usr/bin/sg -> newgrp* Not an suid in the bunch! And as for your intention that the other bits are set to 711 ... not happening, and my build log shows 4755. My build log shows that these guys have their suid bit set when they are installed into /var/tmp/portage/shadow-4.0.4.1-r4/image/usr/bin, so the problem must be occuring after that. The man page for "cp" says all permission bits are masked with 0777 (which would clear suid) unless "-p" is given. Maybe something like that is happening. Portage 2.0.50-r11 (default-x86-1.4, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.6-rc1) ================================================================= System uname: 2.6.6-rc1 i686 Intel(R) Pentium(R) 4 CPU 2.60GHz Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control"CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.seren.com/gentoo ftp://mirror.iawnet.sandia.gov/pub/gentoo/ http://cudlug.cudenver.edu/gentoo/ http://mirror.tucdemonic.org/gentoo/" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa apm avi berkdb bitmap-fonts bonobo cdr crypt cups dga doc dvd dvdr emacs encode f77 foomaticdb gdbm gif gnome gpm gtk gtk2 gtkhtml guile imlib jack java jikes jpeg libg++ libwww mad mikmod mmx motif mozilla mpeg mysql ncurses nls oggvorbis opengl oss pam pda pdflib perl png ppds python quicktime readline scanner sdl slang spell sse ssl tcltk tcpd tiff truetype usb video_cards_radeon videos x86 xml2 xmms xprint xv zlib"
i dont know where you see a 'cp' but there arent any with shadow ... it uses 'install' please run `emerge shadow >& log` and post the log file
Created attachment 42142 [details] emerge log file Here's the log file from reinstalling shadow-4.0.4.1-r4. Although I had r4 already installed and the suid bits manually set, this latest emerge reset them (as anticipated). After creating the attached log, I stepped through the shadow ebuild. After completing the "install" step, I inspected the binaries and found that the suid bits were *missing* from the files in /var/tmp/portage/shadow-4.0.4.1-r4/image/bin and usr/bin. What's up with that? The log shows chmod is doing it's thing in that directory, yet the bits were clear. So I added some diagnostic messages to the install phase in the shadow ebuild file. They showed that while src_install() is executing, the suid bits is set. Sometime after src_install() returns, the bits are cleared. I don't know where ebuild goes after that. Somewhere in Python code. Gimme a hint, and I'll try to trace through it. Sorry about the incomplete thought regarding "cp". I meant to suggest that the setuid bit may be cleared during the qmerge step, but now I believe it's somewhere near the end of the install phase.
if you do `FEATURES=-noauto ebuild [shadow ebuild] install` and go into the image dir yourself, are the setuid bits there ?
No, they are not there. FEATURES=-noauto appears to have made no difference.
and you had a check at the very end of src_install() ? ls -l $D/bin $D/sbin $D/usr/bin $D/usr/sbin
Sorry, no I didn't. I'll try again... Yes, with the FEATURES=-noauto flag, the suid bits are enabled at the end of src_install(). The bits are somehow cleared by the time ebuild finishes. I'm not sure what FEATURES=-noauto does, but it doesn't seem to make a difference for these suid bits. I seem to get the same result as reported in Comment #6.
ok, well if the problem lies in portage-2.0.51, i cant offer much help ... i tend to just let others fix portage problems when the issue lies with the python code ;)
Just tested this... touch /root/dar; chmod u+s g+s /root/dar; cd /root ; install dar /root/dar2; ls -l dar2 -rwxr-xr-x Looking at the log, /bin/sh ../libtool --mode=install /bin/install -c groups /var/tmp/portage/shadow-4.0.4.1-r4/image//bin/groups /bin/install -c groups /var/tmp/portage/shadow-4.0.4.1-r4/image//bin/groups That install call is wrong, install defaults to it's norm for perms, thus stripping suid/sgid. Makefile/libtool is horked, portage is fine.
true, but if you scroll down the log a bit further ... /bin/sh ../libtool --mode=install /bin/install -c passwd /var/tmp/portage/shadow-4.0.4.1-r4/image//usr/bin/passwd /bin/install -c passwd /var/tmp/portage/shadow-4.0.4.1-r4/image//usr/bin/passwd <snip> for i in chage chfn chsh expiry gpasswd newgrp passwd; do \ chmod 4755 /var/tmp/portage/shadow-4.0.4.1-r4/image//usr/bin/$i; \ done
After using ebuild to unpack, compile and install, I get the following: localhost image # pwd /var/tmp/portage/shadow-4.0.4.1-r4/image localhost image # ls -l bin/* usr/bin/* -rwxr-xr-x 1 root root 6388 Oct 30 10:37 bin/groups -rws--x--x 1 root root 27728 Oct 30 10:37 bin/passwd -rws--x--x 1 root root 24476 Oct 30 10:37 bin/su -rws--x--x 1 root root 38064 Oct 30 10:37 usr/bin/chage -rws--x--x 1 root root 29780 Oct 30 10:37 usr/bin/chfn -rws--x--x 1 root root 29624 Oct 30 10:37 usr/bin/chsh -rws--x--x 1 root root 18388 Oct 30 10:37 usr/bin/expiry -rwxr-xr-x 1 root root 7936 Oct 30 10:37 usr/bin/faillog -rws--x--x 1 root root 37196 Oct 30 10:37 usr/bin/gpasswd -rwxr-xr-x 1 root root 6252 Oct 30 10:37 usr/bin/lastlog -rws--x--x 1 root root 24280 Oct 30 10:37 usr/bin/newgrp lrwxrwxrwx 1 root root 16 Oct 30 10:37 usr/bin/passwd -> ../../bin/passwd lrwxrwxrwx 1 root root 6 Oct 30 10:37 usr/bin/sg -> newgrp Then after using ebuild to qmerge or just emerging from scratch, I get: localhost / # ls -l $(cat /var/db/pkg/sys-apps/shadow-4.0.4.1-r4/CONTENTS | grep /bin/ | awk '{print $2}') -rwxr-xr-x 1 root root 6388 Oct 30 10:42 /bin/groups -rws--x--x 1 root root 27728 Oct 30 10:42 /bin/passwd -rws--x--x 1 root root 24476 Oct 30 10:42 /bin/su -rws--x--x 1 root root 38064 Oct 30 10:42 /usr/bin/chage -rws--x--x 1 root root 29780 Oct 30 10:42 /usr/bin/chfn -rws--x--x 1 root root 29624 Oct 30 10:42 /usr/bin/chsh -rws--x--x 1 root root 18388 Oct 30 10:42 /usr/bin/expiry -rwxr-xr-x 1 root root 7936 Oct 30 10:42 /usr/bin/faillog -rws--x--x 1 root root 37196 Oct 30 10:42 /usr/bin/gpasswd -rwxr-xr-x 1 root root 6252 Oct 30 10:42 /usr/bin/lastlog -rws--x--x 1 root root 24280 Oct 30 10:42 /usr/bin/newgrp lrwxrwxrwx 1 root root 16 Oct 30 10:42 /usr/bin/passwd -> ../../bin/passwd lrwxrwxrwx 1 root root 6 Oct 30 10:42 /usr/bin/sg -> newgrp Looks the same to me. Ie. I can't reproduce this. The permissions seem pretty strange though.
Well, something is clearing those bits in the image directory after src_install() finishes on my system. I have other programs installed which do successfully set the suid bit (e.g. /bin/mount from sys-apps/util-linux), so it has worked. As a test, I just now reinstalled util-linux and it set the suid bits correctly -- so util-linux installs correctly with the same portage that fails with shadow. Although not reproducable on some other systems, it is reproducable on mine, so I suggest debugging further on mine. I'm familiar with the portage source only enough to know that it would take me a while to find the code which runs after src_install() completes. But if somebody would point me in the right direction, I can trace through the code.
Can you possibly run portage in debug mode (emerge -debug blah) and paste it here? Also an strace might be nice to in case it's trying to access weird files.
Is the difference between the machines that work and the machines that don't portage-2.0.50-r11? Can you upgrade the machine that is having problems and try again please?
Created attachment 43058 [details] emerge log file, -debug enabled Here is an emerge log file for shadow, with -debug enabled. This took an incredibly long time to produce -- the -debug option caused 64 packages to rebuild! This was not due to out-of-date dependencies, because when I ran it again (this time with --pretend), emerge wanted to rebuild them all over again! Anyway, I don't see an obvious problem here. The reason I upgraded util-linux (see Comment #15) is to verify that another package requiring suid does install correctly with the same portage. I have been using 2.0.50-r11 for a while.
Created attachment 43059 [details] "emerge shadow" strace log In this strace log, it seems that the perms on /bin/su are changed to 0711. I'm guessing this is in the qmerge step.
you were supposed to do --debug not -debug ;)
Created attachment 43075 [details] test.py Please try the following with the attachment in any location: touch test.txt ; touch test2.txt ; chmod +s test.txt ; ./test.py I'd like to verify the output and see if python isn't doing something crazy.
Looks like python is working correctly: $ ls -l *.txt -rwsr-sr-x 1 craig craig 0 Nov 2 23:58 test.txt* -rw-r--r-- 1 craig craig 0 Nov 2 23:58 test2.txt $ ./test.py Permissions for test.txt are 36333 Permissions for test2.txt are 36333 $ ls -l *.txt -rwsr-sr-x 1 craig craig 0 Nov 2 23:58 test.txt* -rwsr-sr-x 1 craig craig 0 Nov 2 23:58 test2.txt* I don't think it's Python -- I recently re-emerged util-linux to verify that emerge was able to set the suid bit on /bin/mount (see Comment #15). Worked fine.
Not a python bug, bash bug in dyn_install. Genone spotted this one, both branches of cvs have it corrected.
this went out a while back...
