Using task_for_pid on Mac OS X

Prior to the Mac OS X 10.5 (Tiger), it was completely legal for one process to modify another for the purpose of controlling its execution (single stepping, resuming, stopping etc) and inspecting/modifying its memory. In Tiger, this policy was modified so that only a process owned by root or with a primary effective group of procmod or procview has this privilege. In Leopard (Mac OS X 10.5), this policy was changed such that a debugger process now depends on the security framework to authorize use of the task_for_pid system service which gives a process the capability to control another process. The details are in the man page for the taskgated daemon. The default launch configuration for this daemon (in the file /System/Library/LaunchDaemons/ runs the daemon in the aforementioned Tiger mode.

The reason I mention all this is that the Maxine VM has a companion tool (called the Inspector) that is used for debugging a running instance of the VM. That is, the Inspector process needs the ability to control the VM process. Up to (and including) Leopard, the Inspector was 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 executable used 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 that can be exploited by other Java programs run by the same executable. This was considered tolerable for 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 inspector on 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 and permission bits of the java executable is no longer possible on Snow Leopard. So, what is an Inspector user on Snow Leopard to do?! Unfortunately, the current solution is to force the Inspector to be launched as root via sudo.

However, the ideal solution is to use the Authorization Services on 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 code provided by Apple, I would have thought the following code is sufficient to acquire the privilege for calling task_for_pid:

#include "auth.h"
#include <Security/Authorization.h>
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:

Authentication dialog for acquiring right to call task_for_pid

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[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 \\

However, a following call to task_for_pid returns an error code of 5 (i.e. a generic kernel failure). At this point, I'm at a loss as to what extra steps are required to convince the OS that I indeed have the permission to debug one of my own programs!


Add an "allow" permission for system.privilege.setugid_appkit to /etc/authorization. Follow the examples in the file. This will allow your java modification to run again. Beware typo's can leave the system unbootable. ( I did that experiment. )

Posted by Ken K on December 29, 2009 at 01:50 PM CET #

I wrote a short blog post how to use task_for_pid on Leopard using self-signed certificate and Security framework so if you are interested - take a look. (

Posted by Ivan Ostres on February 17, 2010 at 03:21 PM CET #

Hi there:

Due to a similar authorization issue (see link below) with Flip4mac and Compressor on Mac OS X Snow Leopard, I have stumbled upon this blog entry and am curious:

Is there any negative consequence to adding the "allow" permission for the setugid_appkit as the post above from "" mentions to do? I'm not familiar with the setugid_appkit so I'm not sure what else I might be allowing for non-admin users, if anything. Can anyone explain what's going on behind-the-scenes when adding this "allow" authorization?

Thank you kindly

Posted by Ben on January 03, 2011 at 12:42 PM CET #

Did you ever figure out how to solve this? I'm trying to solve a similar problem.

Posted by Alex on October 22, 2012 at 10:36 AM CEST #

Unfortunately not. We ended up sticking with the 'sudo' solution for the Maxine Inspector ;-(

Posted by Doug on October 22, 2012 at 10:45 AM CEST #

Actually, I believe I may have figured out the answer: since Snow Leopard, processes have to be signed to request permission to debug other tasks. See

Posted by Alex on October 22, 2012 at 11:22 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed

Doug Simon


« July 2016