Re: [ANNOUNCEMENT] GDB 7.0 release process created

[Jim Ingham <jingham@apple.com>]

Sorry, I don't watch the llvm lists.

My understanding was that the OS Security folks were not planning to  
turn off procmod in SnowLeopard.  A quick test shows the Apple gdb  
built setgid procmod but not codesigned was able to debug.  Maybe now  
you do need the plist (see point 1 below...), though?

At some point, however, the procmod access will go away - or so I was  
told...  Here is the "official" way task port access is granted on  
SnowLeopard (this is what will continue to be supported in the future):

1) In order to have task port access, the process has to request it  
using a plist baked into the binary.  If you look at Apple's gdb  
sources in the src/gdb directory, the plist is in the Info.plist file,  
and it gets added by adding a -sectcreate option to the link line in  
the Makefile.

2) Then the binary also has to be codesigned by some authority that is  
recognized by the user.  You can easily make an appropriate  
codesigning authority with the Certificate Assistant which is part of  
the KeyChain Access tool, or if the FSF already has one that you can  
use, that's even better.  I make an unvalidated one by hand for my own  
development purposes, and there's a target in the gdb Makefile:  
"codesign-gdb" that does the codesigning on the gdb binary if you need  
to see how that is done.  The annoying bit here is that you have to  
ship and install the certificate along with the binary, since the user  
has to say they trust it.

3) There's another trick to this, however, which is that even if you  
fill these requirements, the user will be asked to authenticate to use  
the debugger once per login session.  This is done by the taskgated  
daemon that "task_for_pid" calls down to, and it will put up a dialog  
box if gdb is running in a session that can connect to the Window  
Server.  That's okay for gdb running in a terminal session on your  
local machine, but doesn't work if you are ssh'ed into the machine.   
Fortunately there are API's that you can use to request this  
permission so you can query for the password in the terminal if you  
want.  There's a function "macosx_get_task_for_pid_rights" in the  
SnowLeopard sources for gdb (in macosx-nat-inferior.c) that does just  
that.

The gdb that Apple ships gets special treatment  because it is  
codesigned by the Apple codesigning authority.  I forget all the  
details, but I don't think that this treatment is available to non- 
Apple codesigned apps.

Again, I am pretty sure steps 2 & 3 are NOT necessary for SnowLeopard.

Jim


On Sep 21, 2009, at 6:46 AM, Jack Howarth wrote:

> On Mon, Sep 21, 2009 at 03:35:55PM +0200, Jonas Maebe wrote:
>>
>> Apple's gdb developers are usually quite responsive on Apple's xcode-
>> users list: http://lists.apple.com/mailman/listinfo/xcode-users
>>
>>
>> Jonas
>
> Jonas,
>   I'll wait and see what response I get from my post on llvm-dev first
> (as all the heavy lifting is on llvm/clang at Apple now). Actually, I
> just found out on llvm-dev last Friday that libgcc in Snow Leopard is
> actually subsumed into libSystem now (and the FSF libgcc is never
> actually used). Never heard that anywhere else before. Makes life
> interesting when a compiler is creating exception handling for a  
> completely
> different unwinder than the one actually used at runtime.
>              Jack