Prior to the Mac OS X 10.5 (Tiger), it was completely legal for one process to modify anotherfor the purpose of controlling its execution (single stepping, resuming, stopping etc) andinspecting/modifying its memory. In Tiger, this policy was modified so that only a processowned by root or with a primary effective group of procmod or procviewhas this privilege. In Leopard (Mac OS X 10.5), this policy was changed such that a debuggerprocess now depends on the security framework to authorize use of the task_for_pidsystem service which gives a process the capability to control another process. The detailsare in the man page for the taskgated daemon. The default launch configurationfor this daemon (in the file /System/Library/LaunchDaemons/com.apple.taskgated.plist)runs the daemon in the aforementioned Tiger mode.
The reason I mention all this is that theMaxine VM has a companion tool(called the Inspector)that is used for debugging a running instance of the VM. That is, the Inspector processneeds the ability to control the VM process. Up to (and including) Leopard, the Inspectorwas granted this capability by means of a (somewhat insecure) workaround. Given that the Inspector is itself a Java program, one could simply modify the java executableused to run it. For example:
% sudo chgrp procmod /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bin/java % sudo chmod g+s /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bin/java
It should be obvious of course, that this opens up potential security vulnerabilities thatcan be exploited by other Java programs run by the same executable. This was considered tolerablefor those developers working on Inspector on a Mac. However, with the release of Snow Leopard(Mac OS X 10.6), this workaround was rendered ineffective. If one tries to run the inspectoron Snow Leopard with the altered java executable, the result on the console is:
2009-09-16 11:14:23.307 java[1654:903] The application with bundle ID (null) is running setugid(), which is not allowed.
Not being a very knowledgeable Mac developer (nor wanting to invest the time to become one just yet!),I'm not exactly sure what this means. However, the outcome is that modifying the ownership andpermission bits of the java executable is no longer possible on Snow Leopard. So, whatis an Inspector user on Snow Leopard to do?! Unfortunately, thecurrent solution is to force theInspector to be launched as root via sudo.
However, the ideal solution is to use theAuthorization Serviceson a Mac to dynamically obtain the privileges necessary for the Inspector to use task_for_pid.Unfortunately, use of this framework turns out not to be as straight forward as I thought it would (should!) be.Based on the sample codeprovided by Apple, I would have thought the following code is sufficient toacquire the privilege for calling task_for_pid:
#include "auth.h"#include int acquireTaskportRight() { AuthorizationRef authorization; OSStatus status = AuthorizationCreate (NULL, kAuthorizationEmptyEnvironment, kAuthorizationFlagDefaults, &authorization); if (status != 0) { fprintf(stderr, "Error creating authorization reference\n"); return -1; } AuthorizationItem right = { "system.privilege.taskport", 0, 0 , 0 }; AuthorizationItem items[] = { right }; AuthorizationRights rights = { sizeof(items) / sizeof(items[0]), items }; AuthorizationFlags flags = kAuthorizationFlagInteractionAllowed | kAuthorizationFlagExtendRights | kAuthorizationFlagPreAuthorize; status = AuthorizationCopyRights (authorization, &rights, kAuthorizationEmptyEnvironment, flags, NULL); if (status != 0) { fprintf(stderr, "Error authorizing current process with right to call task_for_pid\n"); return -1; } return 0;}
When executed, this code results in the expected authentication dialog:

When I enter an administrator name and password, the dialog closes and the authorization appears to succeed.This suspicion is supported by the entry written to /var/log/secure.log:
Sep 16 11:11:28 isquawk com.apple.SecurityServer[21]: Succeeded authorizing right 'system.privilege.taskport' by client \ '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bin/java' for authorization created by \ '/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bin/java'
However, a following call to task_for_pid returns an error code of 5 (i.e. a generickernel failure). At this point, I'm at a loss as to what extra steps are required to convince the OSthat I indeed have the permission to debug one of my own programs!

More...