Bug 89057 - can't ptrace an SUID'ed process even as root
can't ptrace an SUID'ed process even as root
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
: 97163 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-16 20:01 EDT by Ramesh Dharan
Modified: 2007-04-18 12:53 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-02 05:36:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
repro case for setuid segv (785 bytes, text/plain)
2003-12-02 05:10 EST, Joe Orton
no flags Details

  None (edit)
Description Ramesh Dharan 2003-04-16 20:01:29 EDT
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:
Comment 1 Ron Yorston 2003-04-30 06:34:20 EDT
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.
Comment 2 Kaya Bekiroglu 2003-05-19 23:41:24 EDT
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. 
Comment 3 John Morrissey 2003-05-23 10:39:30 EDT
I can also reproduce this with errata kernel 2.4.20-13.7 with a daemon that
switches UIDs after it starts up.
Comment 4 Joe Orton 2003-07-08 12:55:32 EDT
This appears to be fixed in 2.4.20-18.8 for 8.0 and 2.4.20-18.9 for 9.
Comment 5 Joe Orton 2003-07-08 12:55:56 EDT
*** Bug 97163 has been marked as a duplicate of this bug. ***
Comment 6 John Morrissey 2003-07-08 12:59:44 EDT
Any chance of a fixed kernel for 7.3?
Comment 7 Richard Phipps 2003-08-08 13:24:49 EDT
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.
Comment 8 Joe Orton 2003-12-02 05:07:56 EST
Confirmed not fixed in 2.4.20-20.9 and 2.4.20-24.7smp.

I'll attach a repro case.
Comment 9 Joe Orton 2003-12-02 05:10:56 EST
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)
Comment 10 Joe Orton 2003-12-02 05:13:36 EST
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.
Comment 11 Joe Orton 2003-12-02 05:36:51 EST
Since ptrace() on setuid processes does now work lets leave bug 104310
to track the prctl(PR_SET_DUMPABLE, 1) problem.

Note You need to log in before you can comment on or make changes to this bug.