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): kernel-2.4.18-27.8.0, kernel-2.4.20-8 How reproducible: Always 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. Additional info:
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 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 child (smbd). 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 prctl(PR_SET_DUMPABLE,1) broken. From proposed patch and following discussion between Alan Cox & Bernhard Kaindl: http://www.ussg.iu.edu/hypermail/linux/kernel/0305.1/0232.html: 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 Failure: # uname -r 2.4.20-24.7smp # ./suidsegv ./suidsegv: dumpable flag not set! Success: # uname -r 2.4.22-1.2115.nptlsmp # ./suidsegv 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.