Description of problem: Since time immemorial, debugging a setuid program has resulted in the program losing all setuid privileges and the debugger operating on it as a normal program. In the fedora 27 kernel, the setuid program still loses privileges, but now PTRACE_PEEKDATA (as an example) always gets an I/O error, so it is no longer possible to operate on the program as normal. Version-Release number of selected component (if applicable): kernel-4.14.7-300.fc27.x86_64 How reproducible: 100% - I'll attach a small test case to demonstrate Steps to Reproduce: 1.Extract tarball 2.Run (as a user with sudo privileges) make 3.See the I/O error Actual results: ptrace error 5 (I/O error) Expected results: ptrace returns data read from the program Additional info: Here is the test running on fedora 26 with 4.11.8-300.fc26.x86_64 kernel: [nvtest@fed26x ptest]$ make g++ -o ./setuid -g setuid.c sudo chown root ./setuid sudo chmod 4555 ./setuid g++ -o ./trace-setuid -g trace-setuid.c Running ./setuid with no ptrace, this should say root ./setuid root Now running with ptrace ./trace-setuid `./firstload` Success! 0x10102464c457f nvtest Here is the test running on fedora 27 with 4.14.7-300.fc27.x86_64 kernel: tomh> make g++ -o ./setuid -g setuid.c sudo chown root ./setuid sudo chmod 4555 ./setuid g++ -o ./trace-setuid -g trace-setuid.c Running ./setuid with no ptrace, this should say root ./setuid root Now running with ptrace ./trace-setuid `./firstload` PTRACE_PEEKDATA failed: Input/output error tom
Created attachment 1371263 [details] gzipped tarball of ptest test directory Don't extract this to some place like /tmp which is mounted with nosuid because the results will be very confusing.
In case anyone wonders why I need this: If you need to debug something buried down in a complicated startup script, it is much simpler to do that if you can just run the script under the debugger, follow all process creation and really debug once it starts the program of interest. Sometimes these scripts have side effects setting things up down a fork that runs a setuid program. Since the script wouldn't work right if the setuid program lost privileges, I arrange to notice I just execed one, patch code into it to make it re-exec itself, then detach from it, thus allowing things to proceed exactly as they would have if not under the debugger. I'd be more than happy to simplify this if someone added an PTRACE_SETOPTIONS flag that did something like: "rip process away from debugger and detach to let it run with its normal privileges" since that's basically what I do with the much more complicated patch/detach/re-exec sequence. (I guess there would need to be something that let's the debugger know this just happened as well).
More info may accumulate in this lkml thread: http://lkml.iu.edu/hypermail/linux/kernel/1712.2/04964.html There is already one reply pointing at a possible culprit.
I see a patch has now appeared in this thread: http://lkml.iu.edu/hypermail/linux/kernel/1801.0/01341.html
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. As kernel maintainers, we try to keep up with bugzilla but due the rate at which the upstream kernel project moves, bugs may be fixed without any indication to us. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs. Fedora 27 has now been rebased to 4.15.3-300.f27. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you did actually update, we apologize for the inconvenience (there are a lot of bugs). If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days