/bin/cp is crashing when an unprivileged user tries to copy a file from any path to any other path. When running as root it works as expected. $ echo TEST > test_a $ cp test_a test_b Segmentation fault $ sudo cp test_a test_b $ cat test_b TEST mv for example works perfectly: $ mv test_a test_b $ cat test_b TEST With grsecurity correctly reporting the SIGSEGV signal (host has auditing enabled): cp[29942]: segfault at 3e ip 7c8edcf11400 sp 7e1dc4463e38 error 4 in libc-2.6.1.so[7c8edce9e000+137000] grsec: From X.X.X.X: signal 11 sent to /bin/cp[cp:29942] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:7186] uid/euid:1000/1000 gid/egid:1000/1000 grsec: From X.X.X.X: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /bin/cp[cp:29942] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:7186] uid/euid:1000/1000 gid/egid:1000/1000 I've tried rebuilding the glibc, recompiling the kernel changing SLUB back to SLAB, etc. It's rather hilarious that /bin/cp seems to be the only binary faulting this way. I just don't know what could be going wrong there. It seems like some stack frames get corrupted at some point: $ gdb /bin/cp GNU gdb 6.7.1 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r test_b test_a Starting program: /bin/cp test_b test_a (no debugging symbols found) (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. 0x000072e7a678f400 in ?? () (gdb) back #0 0x000072e7a678f400 in ?? () #1 0x000072e7a6760671 in ?? () #2 0x0000000000000000 in ?? () (gdb) x/i $rip 0x72e7a678f400: cmpb $0x0,(%rax) That's just messed up. Reproducible: Always Steps to Reproduce: 1. Create a file as unprivileged user 'test_a'. 2. Attempt to cp test_a to test_b or any other file. 3. /bin/cp crashes, but if it runs as root, files copies fine. Actual Results: /bin/cp crashes on a bogus location and won't work at all when running by an unprivileged user. Expected Results: /bin/cp should certainly not die there :) Portage 2.1.4.4 (hardened/linux/amd64/2008.0, gcc-3.4.6, glibc-2.6.1-r0, 2.6.25-hardened-r4 x86_64) ================================================================= System uname: 2.6.25-hardened-r4 x86_64 Intel(R) Xeon(R) CPU X3210 @ 2.13GHz Timestamp of tree: Sat, 06 Sep 2008 00:18:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.4-r6, 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.61-r2 sys-devel/automake: 1.5, 1.7.9-r1, 1.10.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=nocona -fforce-addr" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -pipe -march=nocona -fforce-addr" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://distro.ibiblio.org/pub/linux/distributions/gentoo/ " LDFLAGS="-Wl,-O1" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY=" " SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="acl amd64 apache2 bash-completion berkdb bzip2 clamav cli cracklib crypt cups curl dri enscript fastcgi gdbm gmp gpm hardened iconv imap imlib ipv6 isdnlog java jpeg justify libwww maildir mailwrapper mbox memlimit mhash midi mktemp mmx mudflap multilib mysql mysqli ncurses nls nptl nptlonly ogg openmp pam pcntl pcre perl php pic png postfix pppd python readline reflection rrdtool rss ruby sasl session sockets socks5 spl sqlite sqlite3 sse sse2 ssl subversion svg sysfs tcpd tidy tiff tls truetype unicode urandom vhosts vorbis xattr xml xmlrpc xorg xpm zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias auth_digest log_forensic proxy proxy_ajp proxy_balancer proxy_connect proxy_ftp proxy_http" APACHE2_MPMS="prefork" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="fbdev glint i810 mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Downgrading to emerge -a =sys-apps/coreutils-6.9-r1 makes it work again. I'll test the newer versions and see what was the latest one working properly.
None of the newer versions worked so far. Only downgrading to 6.9-r1 works. Non-working versions: coreutils-6.10-r1.ebuild coreutils-6.10-r2.ebuild coreutils-6.11.ebuild coreutils-6.12-r1.ebuild
This effectively kills some critical boot time tasks when mktemp is missing. Old coreutils ebuilds lack of mktemp and the separate mktemp ebuild is necessary (which blocks with the newer coreutils ebuilds obviously). I will check if vanilla coreutils works properly once I get the data center people to stop ignoring our instructions to get the machine back online.
How about building one of the misbehaving coreutils with debugging enabled? Maybe just use 'ebuild' utility to run compile stage and run 'cp' under gdb from the build directory (so you can leave the working older coreutils on your system until this issue is solved).
Assigning to hardened team, who seem most likely to have run across similar problems (base-system maintainers are already cc-ed in case they want to jump in here)
(In reply to comment #4) > How about building one of the misbehaving coreutils with debugging enabled? > Maybe just use 'ebuild' utility to run compile stage and run 'cp' under gdb > from the build directory (so you can leave the working older coreutils on your > system until this issue is solved). > Done with upstream/vanilla coreutils 6.12 and it worked fine. Now the issue seems gone after a reboot. This is kind of strange. It seems like it's going to be a problem of hardened-sources on amd64 and this particular setup. memtest shows no problems with the memory modules. Also, coreutils < 6.10 should warn about missing mktemp when unmerging/emerging. People downgrading to coreutils-6.9 will find out mktemp is not available and they will have trouble booting up properly. They need to re-emerge the separate mktemp ebuild.
Can you try with gdb 6.8-r1 in portage that works with pie?
This actually manifests in non-hardened profiles as well. Using the default/linux/amd64/2008.0 profile, I started seeing this problem when booted to gentoo-sources-2.6.27-r1. Re-compiling sys-apps/coreutils-6.12-r1 _without_ the 'xattr' USE flag has temporarily alleviated the issue.
I'm seeing this (or something similar) in other applications (semi-stable 2008.0 x86 profile) kernel gentoo-sources-2.6.27-r2: Nov 14 04:20:11 cool mythfilldatabas[5582]: segfault at bc9a74d0 ip 081760c7 sp b4806d1c error 6 Nov 14 22:13:08 cool gplink[7007]: segfault at 0 ip b7e0c709 sp bfd0ef00 error 4 in libc-2.6.1.so[b7d9f000+129000] Nov 14 22:13:55 cool gplink[7030]: segfault at 0 ip b7e55709 sp bfc58650 error 4 in libc-2.6.1.so[b7de8000+129000] That was media-tv/mythtv-0.21_p18812 I think (I've just updated to media-tv/mythtv-0.21_p19046 and restarted the backend to see if it's fixed). gputils is now dev-embedded/gputils-0.13.6-r1, but I may have been running the stable version 0.13.3 when the faults occurred (I had to upgrade to get support for the pic16f887, and it seems ok now).
Since updating mythtv I still got a segmentation violation: Nov 16 04:47:48 cool mythfilldatabas[3296]: segfault at 7f ip 08197753 sp b45f9d18 error 6
Since reverting to kernel gentoo-sources-2.6.26-r3, the mythfilldatabase segfaults have gone. Perhaps this should be a separate bug report...
probably dupe of Bug 217290
*** This bug has been marked as a duplicate of bug 217290 ***
