Unable to find Mach task port for process-id 28860: (os/kern) failure (0x5).Searching the web for such messages I see this rumor.
I cannot now find the web page but I believe that I saw a note from someone at Apple saying that access to Unix processes such as required by gdb to debug a process, had been restricted so that a person using gdb would no longer be able to abuse the authority of a setuid program running under gdb. I.e. after “gdb /usr/bin/passwd” any user would be able to do things that only root should be able to do. The seeming result of this is that I can’t debug ‘Hello World’ without giving both gdb and my program root access.
With great trepidation I tried “gdb /usr/bin/passwd” just now. It worked; or at least it got to the point of asking me for my old password. I did not have the nerve to continue. Now I am worried!
I did a test with two different users. The simplest explanation of what I saw is that under gdb the program runs with the authority of the user who launched gdb even if the file from which the binary was loaded was marked setuid. Perhaps this is a mod to gdb which is certainly in a position to do this, except for the fact that neither /usr/libexec/gdb/gdb-i386-apple-darwin nor /usr/bin/gdb are marked setuid. I don’t know how Apple does this but I see no clear vulnerability. Perhaps we are in getxattr land.
Modifying the kernel to make access to a process contingent on the accessor having as much authority as the accessed process would alleviate all of the issues that I remember from the Apple note, and then I could debug ‘Hello World’ without root access for either gdb or my undebugged program.
I think that I have the answer. See this. When I mark as ‘trusted for code signing’ Apple’s 509 cert with MD5 fingerprint = 7E 61 1E 0F 7B A3 1B 51 98 6F 41 3B 41 38 3E F0, then gdb executes the program with no problems or reservations. I do this step with Apple’s Keychain utility which ascribes the name “Apple Root CA” to that cert.