Hello, this appears to be working as designed.
In Linux, process tracing is tied with the process dumping flag. The
dumpable flag is cleared at execve(2) time when a setuid or setgid
application is executed. This flag persists to child processes created
by fork(2) and will only be reset when a process calls execve(2) again.
The server.c program does not call any of the exec() family of
functions, nor system(3). Thus the flag is never set in the child
process.
You may be able to amend your application to call prctl(2) with
PR_SET_DUMPABLE if you wish to be able to trace the child. I will
caution you that the child may contain private data from the parent in
either shared memory segments that are open in both, copied memory
segments, duplicated file descriptors, etc. It would be better to change
your application design to use an execve(2) when starting a child
process that must be traced to ensure that a minimum of resources are
shared between parent and child.
Many thanks for the very clear description and source code. It really
helped me to understand what you were seeing and why.
Thanks
** Changed in: linux-signed (Ubuntu)
Status: New => Won't Fix
--
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
