get_memory_info and get_cpu_times failing with AccessDenied for PID 0 or when run as non-root user

[giampaolo]

From jlo...@gmail.com on September 21, 2010 01:10:48

What steps will reproduce the problem?  
1. Log in as root
2. execute the following: 

import psutil
psutil.Process(0).get_memory_info()

3. Same thing occurs when attempting to query a process as a regular 
user, even if started by the same user (works OK if it's run against its own process)


Basically, OS X is throwing AccessDenied for everything if you're not 
a root user, and even root isn't able to query the PID 0 
(kernel_task) process. Libtop and ps are able to get this information 
with setuid libraries. Need to investigate to see if it's possible to 
work around this somehow without also needing to setuid psutil.

If there's no workaround, perhaps we can at least provide a simple 
mechanism/instructions to setuid our lib for users who choose to do so.

Original issue: http://code.google.com/p/psutil/issues/detail?id=108

[giampaolo]

From g.rodola on September 21, 2010 11:41:45

Labels: Milestone-0.2.0

[giampaolo]

From jlo...@gmail.com on October 23, 2010 11:52:07

I'm going to close this as WontFix for now since there is no 
workaround I can find. However, I've modified the code in r727 to 
allow us to ignore AccessDenied errors for the mach calls on OS X and 
still get any other data we can.

Status: WontFix

[giampaolo]

From jlo...@gmail.com on October 26, 2010 19:15:58

Just to close the loop on this - as far as I can tell, the official 
workaround/solution is to use a process similar to that outlined in 
the blog post http://os-tres.net/blog/?p=20 (PDF version attached)

I tested this and it does work. However, it has to be done for the 
*process* which means doing all this for the Python executable, as 
opposed to the psutil library. This makes it even less practical IMO 
than using something like sudo would be, and I can't see this being 
worthwhile unless you needed to use this under some very strict 
security policies that preclude sudo/setuid.

Another alternative for such a case would be to create a python 
binary from your script using freeze or similar tool, and then code 
signing that binary as outlined in the blog post. It should work and 
would avoid needing to do so for the entire python interpeter, but at 
the cost of dealing with freeze and having the overhead of 
essentially embedding the python interpreter into a big binary etc.

Attachment: task_for_pid_signing.pdf

[giampaolo]

From g.rodola on October 27, 2010 01:15:02

I suggest we add a new, say, "OS X notes" section in the 
documentation to clarify this aspect.

[giampaolo]

From g.rodola on March 02, 2013 03:54:24

Updated csets after the SVN -> Mercurial migration: r727 == revision 440ab883f4d8