Seth, thank you kindly for your prompt and clear answer. I modified server.c and confirm that gdb can now attach to the child process. Although prctl(PR_SET_DUMPABLE, 1) has no effect (and returns 0!) when called before resetting privileges, it works after the gid has been reset to the debugging process's gid.
I see where it's documented now. PR_SET_DUMPABLE is not mentioned in /etc/sysctl.d/10-ptrace.conf, but ptrace_scope in procfs(5) refers us to ptrace(2), which says, under PTRACE_ATTACH, "Processes that are not dumpable ... can not be attached via ptrace(2) PTRACE_ATTACH." The elided text refers to prctl(2), wherein the description of PR_SET_DUMPABLE describes how processes come to have their dumpable flag reset to 0. It's all there if you know where to look. Yet that's a bit thin, isn't it? I missed it, and my question on SO failed to elicit any pointer to PR_SET_DUMPABLE. IMO the gdb message in response to failing to attach is too wordy and basic. The focus on ptrace is almost misdirection, insofar as PTRACE_ATTACH is controlled by the union of ptrace_scope and the dumpable flag. I'm not sure what to suggest. A note in the gdb man page would be good. Maybe best would a file in /usr/share/doc/linux-doc describing debugging, dumpability, and ptrace from a programmer's point of view. ISTM one shouldn't have to understand the ptrace(2) syscall to use gdb on running processes. Thanks again for your help. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed in Ubuntu. https://bugs.launchpad.net/bugs/1860822 Title: ptrace fails with yama/ptrace_scope=0 Status in linux-signed package in Ubuntu: Won't Fix Bug description: I cannot attach to a process with gdb despite setting ptrace_scope to 0. The process has no capabilities, and is running under my uid & gid. The process is a child, forked from a privileged program that has divested itself of its parent's privileges. The parent is setgid and has some capabilities. None of that is true of the child. First, the OS: $ lsb_release -rd Description: Ubuntu 16.04 LTS Release: 16.04 The ptrace setting: $ nl /proc/sys/kernel/yama/ptrace_scope 1 0 Me: $ echo uid: $(id -u) gid: $(id -g) uid: 1000 gid: 1000 The test program (source included with this PR): $ ls -ln server -rwxrwsr-x 1 1000 1002 17760 Jan 24 17:30 server $ getcap server server = cap_dac_read_search,cap_sys_ptrace+ep Please note it is setgid to the group 1002, not my gid. The "server" program forks a child. That child 1. reports its uid and gid: effective, real, and saved, and its capabilities 2. removes its capabilities with cap_set_proc and disclaims its gid with setregid(getgid(), getgid()) 3. reports its uid and gid, and capabilities again 4. pauses with pause(2). Although the child reports everything is in order, gdb still cannot attach to it. To facilitate testing, the child writes its pid to a fifo named on the command line. That lets the following script read the pid from the fifo and conveniently demonstrate the whole problem: [snip] $ echo q | sh -x ./run + set -e + rm -f fifo + mkfifo fifo + ./server fifo child 18876 paused awaiting SIGCONT inherited: user 1000, euser 1000 inherited: group 1000, egroup 1002 inherited: ruid 1000, euid 1000, suid 1000 inherited: rgid 1000, egid 1002, sgid 1002 inherited capabilities: '= cap_dac_read_search,cap_sys_ptrace+ep' new: user 1000, euser 1000 new: group 1000, egroup 1000 new: ruid 1000, euid 1000, suid 1000 new: rgid 1000, egid 1000, sgid 1000 new capabilities: '=' + read pid + echo child is 18876 child is 18876 + gdb -q -p 18876 Attaching to process 18876 Could not attach to process. If your uid matches the uid of the target process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf ptrace: Operation not permitted. (gdb) + kill -s CONT 18876 child exited [pins] This appears to be a bug that affects everyone using gdb on Ubuntu. If so, many dealing with privileged processes are working around it by running gdb as root. It's not clear to me that's an improvement on the status quo ante, before the ptrace_scope control was introduced. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-169-generic 4.4.0-169.198 ProcVersionSignature: Ubuntu 4.4.0-169.198-generic 4.4.197 Uname: Linux 4.4.0-169-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.21 Architecture: amd64 Date: Fri Jan 24 17:03:29 2020 InstallationDate: Installed on 2016-07-15 (1288 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.3) ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: linux-signed UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1860822/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
