Apple

On Jul 8, 2009, at 3:43 AM, Aron-Zvi wrote:

Thanks for the detailed reply Terry.

I've tried running the entire thing as root by switching with su before running the command. I've even tried logging in as root.
gdb --args ./gdb fooprogram as root still results in "Unable to find Mach task port for process-id pid_of_ fooprogram (os/kern) failure (0x5)" in the debugee gdb when attempting to run fooprogram.
Once again, this happens in macosx_ptrace_him() after task_for_pid() .

How do I get this working?

Thanks in advance,

Aron-Zvi

On Wed, Jul 8, 2009 at 9:55 AM, Terry Lambert <email@hidden> wrote:
On Jul 7, 2009, at 6:34 PM, Aron-Zvi wrote:
Hey guys,

I've downloaded and built the most recent gdb available at opensource.apple.com - gdb-966.
I'm running OS X Leopard 10.5.7.

I'm stepping through gdb with gdb like so: gdb --args ./gdb fooprogram

gdb fails in macosx_ptrace_him() following the task_for_pid() call. task_for_pid() returns 5 which i believe is KERN_FAILURE. The message displayed in the debugger is "Unable to find Mach task port for process-id 8455".

When I run just ./gdb fooprogram - everything works fine.
gdb's gid is set to procmod. Furthermore, I've even tried running gdb as root with identical results.

How can I use gdb to step through gdb debugging another process?

As a setgid program, you will be unable to debug it unless you run the gdb you are using to debug it as root.

This is an intentional security feature in task_for_pid() and in ptrace() to preclude you using the debugger to debug a program with escalated privilege and thus access code, data, or interfaces which you would otherwise not be privileged to access or execute as a privileged user or group. It doesn't matter that the group is the same as gdb itself is running as, what matters is that the credential for that user has been adulterated away from the identity given to the system by DirectoryServices or whatever authentication database you are using to establish the credential in the first place. Credentials are established by escalating privilege, setting up the credential, and dropping privilege. If you run a program that re-escalates privilege, unless it does the little dance to establish its rights to establish a new kernel credential authoritatively, privilege is revoked. In your case, your gdb is only sgid, so it's incapable of obtaining root privilege in order to become an authoritative source of credential information for the kernel. This is also generally why we ask people to rely on login as a gatekeeper, rather than writing their own credential establishing code.

-- Terry