Summary: | sys-apps/shadow-4.0.4.1-r3: programs not setuid root | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Malte S. Stretz <gentoo-bugger> |
Component: | [OLD] Core system | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | base-system, chriswhite, craig.lawson |
Priority: | High | Keywords: | InVCS |
Version: | 2004.1 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge log file
emerge log file, -debug enabled "emerge shadow" strace log test.py |
Description
Malte S. Stretz
2004-07-05 06:35:59 UTC
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... |