site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com man taskgated can give you some clue about the requirement to access mach ports. Le 31 mars 2010 à 06:23, Jack Howarth a écrit :
Kevin, I tried...
sudo codesign -s - /sw/bin/fsf-gdb
and I still get...
[MacPro:~] howarth% fsf-gdb ./a.out GNU gdb (GDB) 7.1 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-apple-darwin10.3.0". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /Users/howarth/a.out...(no debugging symbols found)...done. (gdb) break main Breakpoint 1 at 0x100000f4e (gdb) r Starting program: /Users/howarth/a.out Unable to find Mach task port for process-id 44895: (os/kern) failure (0x5). (please check gdb is codesigned - see taskgated(8))
whereas 'sudo fsf-gdb ./a.out' works fine. Looking at the two binaries I see...
[MacPro:~] howarth% codesign -d -vvv /usr/libexec/gdb/gdb-i386-apple-darwin Executable=/usr/libexec/gdb/gdb-i386-apple-darwin Identifier=com.apple.gdb Format=Mach-O universal (i386 ppc7400 x86_64) CodeDirectory v=20100 size=17922 flags=0x0(none) hashes=891+2 location=embedded CDHash=1f961159e2c4038e658298a52b2f295ff95b2266 Signature size=4064 Authority=Software Signing Authority=Apple Code Signing Certification Authority Authority=Apple Root CA Info.plist entries=6 Sealed Resources=none Internal requirements count=1 size=180
[MacPro:~] howarth% codesign -d -vvv /sw/bin/fsf-gdb Executable=/sw/bin/fsf-gdb Identifier=org.gnu.gdb Format=Mach-O thin (x86_64) CodeDirectory v=20100 size=25960 flags=0x2(adhoc) hashes=1293+2 location=embedded CDHash=99c0613857a480e69f36eacc158a2d78f2f199af Signature=adhoc Info.plist entries=4 Sealed Resources=none Internal requirements count=1 size=104
Is it significant that Apple's gdb has flags set to 0x0 whereas the fsf-gdb shows flags set to 0x2? Any other ideas to try? Jack
On Tue, Mar 30, 2010 at 09:23:17AM -0700, Kevin Van Vechten wrote:
The behavior you describe is the result of changes in recent Mac OS X releases to restrict the use of task_for_pid and related functions that present significant security risks. The goal is to limit use of such functions to the system administrator, and the policy is enforced by the taskgated process. Code signing is required in order to verify that the binary is not maliciously changed out from under any previous approval for use of these functions. Nothing about this policy is unique to gdb.
It's possible to generate "ad hoc" code signatures on binaries which generate all the usual checksums for the purposes of integrity checks but do not chain to a trusted authority. It's worth giving the following a try to see if it satisfies the basic requirements of taskgated (I haven't tried it myself):
$ sudo codesign -s - /path/to/gdb
Kevin
On Mar 30, 2010, at 7:18 AM, Jack Howarth wrote:
I am trying to prepare fink packaging of the new FSF gdb 7.1 release on i386 and x86_64 fink. Unfortunately Apple's changes in 10.5.8 or later require that gdb binary be code signed (or run as root) in order to access the required Mach port for debugging code. Are their any code signing gurus here who could suggest the best approach to cope with this problem? I am hoping to implement something along these lines but am unsure if it is feasible.
1) Provide an openssl certificate bundled with the fsf-gdb fink package. 2) Provide a shell script which when run, guides the user through the steps of loading the provided certificate manually in the KeyChain application and then code signs the fsf-gdb binary from within the shell script using command line tools. My understanding is that only the creation and/or loading of the openssl certificates no longer have CLI tool access. 3) Have a postinstall script in the fsf-gdb that would check if the certificate exists in the Keychain when the fsf-gdb package is installed, reinstalled or upgraded and launch the shell script described in step 2 if not present. Otherwise it would just code sign the newly installed fsf gdb binary again.
Thanks in advance for any advice on these issues. Needless to say, the FSF gdb developers were a tad miffed that this restriction popped up after all the effort to support intel darwin in the official FSF gdb releases. Jack ps It will be essential to have access to a working FSF gdb 7.1 debugger for users who want to use the upcoming FSF gcc 4.5 compiler release. There are changes in debug code generation which are incompatible with the older gdb releases.
Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/devlists%40shadowlab.org
This email sent to devlists@shadowlab.org
-- Jean-Daniel _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com