Description of problem:
I've verified that this happens with any of the ptrace-patched kernels, i.e.
2.4.18-27.8.0 for RH8 or 2.4.20-8 for RH9, and *does not* happen on an earlier
kernel (stock RH8 2.4.18-14).
It's pretty obvious that this broke as a result of the ptrace patch. At any
rate, you can't ptrace an SUID'ed process even as root. Running as root and
attempting to ptrace such a process, gdb reports "Can't get registers: operation
not permitted" and then proceeds to wedge itself. It won't permit you to quit
since the detach operation fails, and you have to kill gdb.
The gdb problem is obviously a side effect, but it seems strange and wrong to
disallow ptracing an SUID'ed process when you already have root privileges.
Moreover, even if you start the process *as root*, you still can't attach to it!
I doubt this could possibly do anything other than inconvenience a developer ;-).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start an SUID'ed process e.g. passwd, crontab, chsh etc.
2. As root, start gdb and attempt to attach.
3. Watch things break.
Actual Results: ptrace fails and gdb wets itself.
Expected Results: Presumably as a regular user, the process should have been
killed (security exploit and what not), and as root, you should have been
allowed to attach.
I think this is the same as the problem I'm seeing. I wanted to strace xfs (to
find out what it's doing that causes xawtv to take ten times longer to start on
RH9 as compared with RH8) and ended up with a hung xfs:
# ps ax | grep xfs
830 ? S 0:00 [xfs]
1125 pts/1 S 0:00 grep xfs
# strace -p 830
trace: ptrace(PTRACE_SYSCALL, ...): Operation not permitted
detach: ptrace(PTRACE_DETACH, ...): Operation not permitted
xlsfonts: pattern "*" unmatched
I see this behaviour with 2.4.20-9 and 2.4.18-27, but not 2.4.18-26.
I can also repro. with 2.4.20-13.9, the latest errata kernel. In my case I'm not running a
process with the SUID bit set, but I am running one which changes it's UID when it spawns a
It is fantastically annoying.
I can also reproduce this with errata kernel 2.4.20-13.7 with a daemon that
switches UIDs after it starts up.
This appears to be fixed in 2.4.20-18.8 for 8.0 and 2.4.20-18.9 for 9.
*** Bug 97163 has been marked as a duplicate of this bug. ***
Any chance of a fixed kernel for 7.3?
Related bug still in 7.3, kernel 2.4.20-19.7, probably also in 8.0
From proposed patch and following discussion between Alan Cox & Bernhard Kaindl:
Description: processes which want to change their dumpable status have
prctl(PR_SET_DUMPABLE, 1) ignored.
Symptom: Impossible to create a core dump of processes which changed uids,
even if the process requests it by calling prctl(PR_SET_DUMPABLE,1)
Problem: The change to the PR_SET_DUMPABLE in sys_prctl was too strict.
It appears the problems specifically with ptrace may have been patched in
recent RH kernels. However, the "prctl(PR_SET_DUMPABLE, 1) ignored" problem
still exists. A patch was proposed in above URL, but a small part of it related
to prctl() has never been applied to RH kernel builds.
Confirmed not fixed in 2.4.20-20.9 and 2.4.20-24.7smp.
I'll attach a repro case.
Created attachment 96278 [details]
repro case for setuid segv
# uname -r
./suidsegv: dumpable flag not set!
# uname -r
Dumping core (probably to /tmp/core.27851)...
Segmentation fault (core dumped)
Actually maybe this maybe be a separate bug, since ptrace *does* now
work on a setuid process, but prctl(PR_SET_DUMPABLE, 0) does not.
Since ptrace() on setuid processes does now work lets leave bug 104310
to track the prctl(PR_SET_DUMPABLE, 1) problem.