Process username / groupname

[giampaolo]

From [email protected] on February 18, 2009 15:38:11

Per conversation with Jay this should be scheduled for 0.1.1 release.
The real effort is the Windows implementation since on OS X and Linux pwd
module already does the work for us.

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

[giampaolo]

From [email protected] on February 18, 2009 06:43:23

Labels: Milestone-0.1.1 Component-Library

[giampaolo]

From [email protected] on February 23, 2009 09:49:02

Labels: -Component-Library

[giampaolo]

From [email protected] on March 01, 2009 10:56:32

Any progress on this front? Yan was working on a patch I think, so if that's 
I don't want to implement it on Windows myself. 

We should implement this on the UNIX side at least. My suggestion is we use pwd
module to create username and groupname properties. The properties should check 
the platform module has a get_username() / get_groupname() attribute, and if so 
that. Otherwise, look for pwd module and use that to translate the UID/GID to 
If neither, raise NotImplemented exceptions.

Status: Started

[giampaolo]

From [email protected] on March 01, 2009 16:45:52

I know that Yan wrote some code but that's all.
I'll try to contact him tomorrow and let you know something more.
I could take care of the UNIX part.

[giampaolo]

From [email protected] on March 02, 2009 03:43:57

Implemented on Linux as r199 .

[giampaolo]

From [email protected] on March 02, 2009 04:50:54

Implemented on FreeBSD and OS X as r200 and r201 .

[giampaolo]

From [email protected] on March 06, 2009 19:23:05

Postponed.

Labels: -Milestone-0.1.1

[giampaolo]

From [email protected] on March 11, 2009 10:43:43

Determining the owner of a process is not trivial on Microsoft Windows. Search 
Internet and you will see how many headaches to programmers are caused by this. 
have identified several ways to accomplish the task, each of them has pros and 


--------------

The first solution I have investigated involves OpenProcessToken and 
GetTokenInformation to retrieve user's and group's SIDs.
This would be the best and most reliable way to get the information we need.
The main  issue is that, even using an administrative account, it is not 
open the token of a process not belonging to the calling user.
The only way to succeed would be to call OpenProcessToken from the SYSTEM 
(tested with Sysinternal's utility psexec).
Unluckily no API calls are provided to promote execution to local system.
Two methods are possible to solve the problem:

1) Use a service. Services usually run within the SYSTEM account.
We have to create and install the service, make it collect the data, create a 
to pass information to the main program, stop the service, uninstall it... It 
a minor programming effort and I am not sure it is worth trying... just to get 
username...

2) Use a driver. This solution, quite effective, goes far beyond my knowledge...

--------------

The second way to get the process owner takes advantage of 
The solution is the simplest I have found, but requires TermService service to 
and running.
On Microsoft Windows 2000 professional, Terminal Services isn't even installed 
default.
I don't think we should rely on the presence of a component that can be easily 
stopped or disabled.

-------------

The third solution is the one I chose. In my opinion it is a good mix of 
and reliability.

The code uses GetKernelObjectSecurity to obtain the process security descriptor 
GetSecurityDescriptorOwner to extract the user's SID.
The program works from any administrative account.
During my tests I only run into a couple of minor problems:

- SYSTEM's processes are mysteriously reported as owned by 
(it's a group!). The adopted workaround was filtering the response and 
with the correct NT AUTHORITY\SYSTEM owner.

- The owner of avp.exe process (belonging to my Kaspersky antivirus) could not 
resolved. This AV has kernel self protection that prevents other processes to 
inner details. I think we can safely skip this problem, the program will report 
owner.

BTW, the first solution proposed is not affected by any of these limitations if 
launched within the SYSTEM account.

MS Windows gives no way to get the local group list bound to the security 
of a process. I solved the problem searching directly for the group membership 
the process owner user. I identified four well known local groups we could be 
interested in (Administrators, Power users, Users and Guests).
Using NetUserGetLocalGroups it is possible to enumerate all the groups a user 
belongs to. The most powerful well known group is returned. Most system users 
(system, local service, network service...) are reported with no group 

Visual studio express 2008 project for the third solution is provided as an 
attachment.

If you compile the code from a new project, don't forget to add Netapi32.lib to 
linker option.

Attachment: psuser2.zip

[giampaolo]

From [email protected] on March 12, 2009 10:43:48

Yan this sounds great, I would definitely agree this is the best solution to go 
based on my research so far. I'm surprised OpenProcessToken() fails for all 
not owned by the calling user, but at least the GetKernelObjectSecurity() method
allows us to read more data. I'll take a look at this in the next couple of 
we'll decide whether we want to go ahead and include username / groupname in the
0.1.2 release or wait for another release.

Thanks!

[giampaolo]

From [email protected] on March 17, 2009 09:19:35

Labels: Progress-0in4

[giampaolo]

From [email protected] on March 21, 2009 14:07:08

Now that we implemented cpu and memory information on all platforms I think we 
focus on cleaning up the current code, stabilize what we've done so far (tests,
etc...), release 0.1.2 and postpone this one for 0.1.3 or 0.2.0.

[giampaolo]

From [email protected] on May 07, 2009 08:12:43

Labels: -Progress-0in4 Progress-3in4 Milestone-0.1.3

[giampaolo]

From [email protected] on May 08, 2009 17:02:03

Implemented Windows username functionality as r383 .

[giampaolo]

From [email protected] on July 13, 2009 18:21:30

Are we done with this issue, or are we still waiting on groupname functionality 
Windows? Is that even possible really since Windows doesn't have group 
processes?

[giampaolo]

From [email protected] on July 22, 2009 15:51:44

Implemented Process groupname on Windows [Rev 418]
Needs testing on Windows 2000 and Windows Vista

[giampaolo]

From [email protected] on July 24, 2009 17:14:48

Could you please update the current groupname docstring (__init__.py) 
behavior on Windows (e.g. in case of multiple groups for the same process the 
powerful one is returned, etc.)?

[giampaolo]

From [email protected] on September 17, 2009 01:55:53

Status: FixedInSVN

[giampaolo]

From [email protected] on September 17, 2009 01:57:42

Status: Fixed

[giampaolo]

From [email protected] on February 17, 2010 11:41:05

Now that username code is fixed and groupname raises an exception as it was 
to do since day one I have a clearer point about the groupname functionnality 

groupname on Windows in summary:

- it works only for processes owned by the current user.

- for all other processes a WindowsError exception is raised (before the error
checking an ampty string was returned).

- if the user belongs to a group incuded in (administrators, power users, users,
guests) the most powerful one is returned. 

- the other groups the user belongs to are omitted (on Windows a single user 
to different groups - this can be easily observed with procexp utility).


Here is a script which shows how the functionnality "looks" right now:

<snippet>
for proc in psutil.process_iter():
    try:
        print proc.groupname
    except:
        print "Error: pid=%s, username=%s" %(proc.pid, proc.username)
</snippet>


The output:

<snippet>
Error: pid=0, username=NT AUTHORITY\SYSTEM
Error: pid=4, username=NT AUTHORITY\SYSTEM
Error: pid=256, username=NT AUTHORITY\SYSTEM
Error: pid=348, username=NT AUTHORITY\SYSTEM
Error: pid=408, username=NT AUTHORITY\SYSTEM
Error: pid=432, username=NT AUTHORITY\SYSTEM
Error: pid=456, username=NT AUTHORITY\SYSTEM
Error: pid=480, username=NT AUTHORITY\SYSTEM
Error: pid=488, username=NT AUTHORITY\SYSTEM
Error: pid=548, username=NT AUTHORITY\SYSTEM
Error: pid=628, username=NT AUTHORITY\SYSTEM
Error: pid=688, username=NT AUTHORITY\SYSTEM
Error: pid=728, username=NT AUTHORITY\NETWORK SERVICE
Error: pid=800, username=NT AUTHORITY\LOCAL SERVICE
Error: pid=860, username=NT AUTHORITY\SYSTEM
Error: pid=888, username=NT AUTHORITY\SYSTEM
Error: pid=268, username=NT AUTHORITY\LOCAL SERVICE
Error: pid=644, username=NT AUTHORITY\NETWORK SERVICE
Error: pid=1096, username=NT AUTHORITY\LOCAL SERVICE
Error: pid=1216, username=NT AUTHORITY\SYSTEM
Error: pid=1476, username=NT AUTHORITY\SYSTEM
Error: pid=1520, username=NT AUTHORITY\SYSTEM
Error: pid=1556, username=NT AUTHORITY\SYSTEM
Error: pid=1588, username=NT AUTHORITY\LOCAL SERVICE
Error: pid=1620, username=NT AUTHORITY\SYSTEM
Error: pid=1648, username=NT AUTHORITY\SYSTEM
Error: pid=1392, username=NT AUTHORITY\SYSTEM
Error: pid=1800, username=NT AUTHORITY\SYSTEM
Error: pid=464, username=NT AUTHORITY\NETWORK SERVICE
Error: pid=516, username=NT AUTHORITY\SYSTEM
Administrators
Administrators
Administrators
Administrators
Administrators
Administrators
Administrators
Error: pid=3064, username=NT AUTHORITY\LOCAL SERVICE
Administrators
Administrators
Error: pid=952, username=NT AUTHORITY\LOCAL SERVICE
Administrators
Administrators
Administrators
Administrators
</snippet>


For all these reasons I think that we should just remove groupname support for 
As for the UNIX platform support I think it doesn't make sense to preserve it 
for 3 reasons:

- I don't like to support only 3 platforms out of 4.

- despite on Unix a user belongs only to a single group the groupname is 
which is not strictly related to processes, in fact utilities like ps, top, etc
dont't include the groupname in their results.

- If for some reason the user wants to know the user groupname he can use the 
module resulting in a single line of python code:
>>> grp.getgrgid(gid).gr_name


I'd like some comments to decide what to do.

[giampaolo]

From [email protected] on February 17, 2010 11:43:38

I have no problem with removing it for now, we can always add the code back in 
later date if someone requests it. I can't really imagine a need for groupname 
you never know, maybe someday someone will come up with a reason!

[giampaolo]

From [email protected] on February 17, 2010 13:00:21

Remove groupname code as r496 .

[giampaolo]

From g.rodola on March 02, 2013 03:39:49

Updated csets after the SVN -> Mercurial migration: r199 == revision 
01f6ebfc172f r200 == revision 5f247ca6869b r383 == revision e2629514408f r496