| Summary: | sys-apps/coreutils-6.12-r1: /bin/cp segmentation fault with hardened profile as unprivileged user | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Larry <research> |
| Component: | Current packages | Assignee: | The Gentoo Linux Hardened Team <hardened> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | critical | CC: | base-system, gengor, gentoo, schism, vdm, zorry |
| Priority: | High | ||
| Version: | 2008.0 | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Larry
2008-09-06 15:04:27 UTC
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 *** |
